Lab 2 – VIPS Requirements 1
Lab 2 – VIPS Prototype Requirements
Jacob Baughman
Nick Bitto
Kyle Bohannon
Chad Pellitt
Eric Schultz
CS411
Janet Brunelle
April 13, 2009
Lab 2 – VIPS Requirements 2
Table of Contents
3
Specific Requirements ............................................................................................................ 4
3.1
Functional Requirements.................................................................................................. 4
3.1.1
VIPS Website ............................................................................................................ 4
3.1.2
VIPS Engine.............................................................................................................. 9
3.1.3
VIPS Database ........................................................................................................ 12
3.1.4
RFID Tags and Barcodes ........................................................................................ 22
3.1.5
Garage Simulation .................................................................................................. 22
3.1.6
Admin Screen/Test Harness .................................................................................... 26
3.2
Performance Requirements ............................................................................................ 28
3.2.1
VIPS Website .......................................................................................................... 28
3.2.2
VIPS Database ........................................................................................................ 28
3.2.3
VIPS Engine............................................................................................................ 28
3.2.4
Garage Simulation .................................................................................................. 29
3.3
Assumptions and Constraints ......................................................................................... 30
3.4
Non-Functional Requirements ....................................................................................... 31
3.4.1
Security ................................................................................................................... 32
3.4.2
Maintainability ........................................................................................................ 32
3.4.3
Reliability................................................................................................................ 33
List of Figures
Figure 1. VIPS Website Layout...................................................................................................... 5
Figure 2. VIPS Engine Algorithms ................................................................................................ 9
Figure 3. Start-of-Day Algorithm ................................................................................................. 11
Figure 4. End-of-Day Algorithm .................................................................................................. 12
Figure 5. VIPS Database Tables ................................................................................................... 13
Figure 6. Barcode Procedure Flow ............................................................................................... 15
Figure 7. RFIDcheck Procedure Flow .......................................................................................... 17
Figure 8. ChangeCount Procedure Flow ...................................................................................... 19
Figure 9. ClearGarage Procedure Flow ........................................................................................ 21
Lab 2 – VIPS Requirements 3
List of Tables
Table 1. Comparison of VIPS Website Security Levels ................................................................. 6
Table 2. Garage Simulation Message Format ............................................................................... 25
Table 3. Assumptions, Dependencies, and Constraints on Prototype Requirements ................... 31
Lab 2 – VIPS Requirements 4
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, barcodes, VIPS 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]
Lab 2 – VIPS Requirements 5
Figure 1. 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]
Lab 2 – VIPS Requirements 6
Table 1. 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
Lab 2 – VIPS Requirements 7
b. Displays the user's data from the VIPS Database
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
Lab 2 – VIPS Requirements 8
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.
Lab 2 – VIPS Requirements 9
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 2. VIPS Engine Algorithms
Lab 2 – VIPS Requirements 10
As the interface between the VIPS Garage Simulation and the VIPS Database, the VIPS
Engine is required to:
1. Monitor messages sent from the VIPS 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:
a. Garage identification number
b. Gate identification number
c. Message type
d. The sensor's data
3. 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.
a. 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.
b. 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
Lab 2 – VIPS Requirements 11
Engine then returns to its waiting state.
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 Test Harness.
The VIPS Engine will implement
4. The start-of-day algorithm, as shown in Figure 3.
Figure 3. Start-of-Day Algorithm
Lab 2 – VIPS Requirements 12
5. The end-of-day algorithm, as shown in Figure 4.
Figure 4. 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 VIPS 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
6. 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
Lab 2 – VIPS Requirements 13
information for the purpose of the demonstration. The VIPS Database tables are shown in Figure
5.
Figure 5. 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:
Lab 2 – VIPS Requirements 14
1. Password check procedure – used when logging into the VIPS Website. It will accept or
reject based on:
a. An alphanumeric username
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]
Lab 2 – VIPS Requirements 15
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)
Changcount
succeed?
0
0
Valid := 1;
Fetch garagecount
values
Insert into history
END
Figure 6. Barcode Procedure Flow
0
Lab 2 – VIPS Requirements 16
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]
Lab 2 – VIPS Requirements 17
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 7. RFIDcheck Procedure Flow
Lab 2 – VIPS Requirements 18
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]
Lab 2 – VIPS Requirements 19
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
0
1
1
1
1
Availvis >=
abs(data)?
Availfac >= abs
(data)?
Availstu >= abs
(data)?
Availstu-data
Availvis + data
Valid = 1;
Fetch garagecount
values
1
1
1
Availvis + data
Valid = 1;
Fetch garagecount
values
0
Availfac + data;
Valid = 1;
Fetch garagecount
values
0
Availstu + data
Valid = 1;
Fetch garagecount
values
END
Figure 8. 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:
0
Lab 2 – VIPS Requirements 20
a. Selecting 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.
Lab 2 – VIPS Requirements 21
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 9. ClearGarage Procedure Flow
Lab 2 – VIPS Requirements 22
3.1.4 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 VIPS 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 VIPS Garage Simulation must respond to commands from the VIPS Test
Harness which are defined in this section.
The VIPS Garage Simulation models hardware in the following manner:
1. The VIPS 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:
Lab 2 – VIPS Requirements 23
a. Garage identification number
b. Gate identification number
c. Message type
d. RFID tag or barcode value as appropriate
6. 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.
7. 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.
8. Rate of traffic flow is controlled by the parameters set by the VIPS Test Harness.
9. 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.
10. The state of the model, to include the garages, each garage's display board, each gate's
open/reject status, the queue of vehicles waiting at entrance gates, the current entry and
exit rates, and the current paused/unpaused status will be displayed animatedly.
The Garage Simulation must respond to commands from the Test Harness in order to
demonstrate prototype functionality. These commands are:
11. Pause – Toggles the paused state of the Garage Simulation.
a. If the Garage Simulation is currently active, it will:
Lab 2 – VIPS Requirements 24
i.
Suspend gates from processing vehicles from their queues
ii.
Suspend vehicles from entering queues for gates
b. If the Garage Simulation is currently suspended, it will:
i.
Resume gates processing vehicles from their queues
ii.
Resume vehicles entering queues for gates
12. Set rate of incoming traffic – Sets the rate at which vehicles enter the entrance gate
queues in vehicles per minute.
13. Set rate of outgoing traffic – Sets the rate at which vehicles enter the exit gate queues in
vehicles per minute.
14. Start-of-day Algorithm – Allocates the reserved spaces for the current date.
15. End-of-day Algorithm – Deallocates the unused reserved spaces for the current date.
[This space intentionally left blank]
Lab 2 – VIPS Requirements 25
[Byte 0]
Garage ID
This specifies the garage number to or from which the messages is traveling.
[Byte 1]
Gate ID
This specifies the gate number to or from which the message is traveling. If the
message is being sent to a display board, the Gate ID byte is irrelevant but still
must be included.
[Byte 2]
Message Type
This specifies the type of sensor from or to which the data is traveling.
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
Gate
Display Board
Open
0
Reject
1
[Byte 3] representing available student spaces.
[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 2. Garage Simulation Message Format
Lab 2 – VIPS Requirements 26
3.1.6 VIPS 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:
a. Garage name
b. Address
c. Capacity for students, faculty/staff, visitors, and total number of spaces
d. Number of entrances and exits
e. Add garage
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
Lab 2 – VIPS Requirements 27
4. Department screen – will allow Parking Services to create and delete departments and set
the manager ID for each department.
The VIPS 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:
5. 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
6. Scenario management – the VIPS Test Harness will provide quick links to predefined
scenarios for the demonstration.
a. Case one – the garage is empty
b. Case two – the garage is full
c. Case three – the garage is full but for one reserved visitor space
d. Case four – the garage is half-full
7. Entry and departure forms – the VIPS Test Harness will provide input boxes allowing
manual entry of pass information, demonstrating what happens for a specific individual.
8. Garage Simulation – the VIPS Test Harness will have several options to change the
configuration of the Garage Simulation, including:
a. Entry/Exit rate
b. Pause
c. Start-of-Day algorithm
d. End-of-Day algorithm
Lab 2 – VIPS Requirements 28
3.2
Performance Requirements
Important components that have performance requirements are the VIPS Website, VIPS
Database, VIPS Engine and the VIPS 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.
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 VIPS Garage Simulation and the VIPS Database. Because it has the
Lab 2 – VIPS Requirements 29
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 VIPS Garage
Simulation within three seconds. This includes:
a. Verifying the input via the VIPS Database procedure
b. Sending the appropriate signal to the VIPS Garage Simulation gate
c. Sending the appropriate signal to the VIPS Garage Simulation display board
2. 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.
3. The VIPS Engine must query the VIPS Database's 'GarageCount' table and update any
discrepancies no less than once every two seconds.
3.2.4 VIPS Garage Simulation
The VIPS Garage Simulation has several specifications regarding the performance of its
simulated hardware. The VIPS 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”
Lab 2 – VIPS Requirements 30
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.
Conditions
The parking environment will be
gated 24 hours
Prototype will only service
visitor requests one at a time
Type
Assumption
Eliminate the need of tracking cars when gates
are open
Assumption Prototype will not deal with mass subscriptions
A computer will be in Parking
Services to facilitate last minute Assumption
requests
Effect on Requirements
Will allow the system to use the same services
for advance and day of purchases
Lab 2 – VIPS Requirements 31
Conditions
A table in the VIPS database
will be used for the blacklist
User passwords will be plain
text
Type
A customer based database will not be created.
Assumption The customer database will be emulated as a
table in the VIPS Database.
Assumption
There will be enough spaces in
the garage at the start of the day
through the entrance or exit
VIPS will have access to Human
Resource records
A CS department laptop is
available to run the application.
The VIPS Engine is used to
process garage traffic
The VIPS Website is used to
process visitor requests
The barcodes used by VIPS will
be unique for each visitor pass
Prototype will not enforce an encryption
algorithm on the user passwords
Allows the visitor parking to be guaranteed
Assumption without the reallocating of subscription spaces,
to allocate visitor spaces
Only one car at a time will pass
Effect on Requirements
prior to the visitor capacity of the garage.
Assumption
Assumption
This allows for the Garage Simulation to
process the barcode/RFID reads one at a time
Allows VIPS to develop the Faculty/ Staff
tables in the VIPS Database.
Dependency If it is not, a student laptop will be used
Dependency
Dependency
Constraint
The prototype VIPS Database will fail if the
VIPS Engine does not work.
The prototype VIPS Database will fail if the
VIPS Website does not work.
Allows VIPS to ensure only one pass will be
issued under any one barcode.
Table 3. 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
Lab 2 – VIPS Requirements 32
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
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.
Lab 2 – VIPS Requirements 33
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.