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 X, is necessary to document any assumptions,
constraints, and dependencies because these will affect the requirements and explain
possible incompleteness of the prototype. For instance, the VIPS will assume that the
garages will be gated 24 hours a day. This assumption allows the VIPS team to focuses
on the innovative functionality of the prototype rather than solving trivial issues. The
development of a limitations table will allow the VIPS team to produce and test a viable
prototype to show functionality as it will relate to the complete product. Table X contains
a complete list of assumptions, constraints, and dependencies associated with the VIPS
prototype.
[This space is intentionally left blank]
Conditions
Type
Effect on Requirements
The parking environment will
be gated 24 hours
Assumption
Eliminate the need of tracking cars when
gates are open
Prototype will only service
visitor requests one at a time
A computer will be in parking
services to facilitate last
minute requests
A table in the database will
be used for the blacklist
User passwords will be plain
text
There will be enough spaces
in the garage at the start of
the day to allocate visitor
spaces
Only one car at a time will
pass through the entrance or
exit
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
Assumption
Assumption
Assumption
Assumption
Assumption
Assumption
This allows for the simulation to process
the barcode/RFID reads one at a time
Dependency If it is not, a student laptop will be used
Dependency
The database of the prototype will fail if
the VIPS engine does not work.
Dependency
The database of the prototype will fail if
the VIPS website does not work.
Cars can only have one RFID
Constraint
tag at a time
Cars will not be able to take
up more than one space
Prototype will not deal with mass
subscriptions
Will allow the system to use the same
services for advance and day of
purchases
A customer based database will not be
created. The customer database will be
emulated as a table in the VIPS
database.
Prototype will not enforce an encryption
algorithm on the user passwords
Allows the visitor parking to be
guaranteed without the reallocating of
subscription spaces, prior to the visitor
capacity of the garage.
Constraint
Eliminates the collusion of two tags
attempting to access the reader at the
same time.
Limits the problem of cars taking up more
than one space. Allows the prototype to
maintain an accurate garage count.
Table X. 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 non-functional 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 ensured
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 visitor are added to the system, their information is
stored internally in the prototype 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 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 laptop and the barcode scanner will be inspected by the VIPS team. This
inspection will include a visual check as well as operational tests. It is very important for
the VIPS team to maintain all software components to include, VIPS database, VIPS
engine, and VIPS website and hardware 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
databases will be able to be accessed to store and query data whenever necessary,
with little to no lag time. The VIPS website must be able to handle multiple access
requests and handle them without degradation of the system. The website must also be
able to route visitor requests to the database. Reliability is a very important aspect to
ensure a successful development of the VIPS prototype.