Res 2009-171 - Laserfiche WebLink

Home Browse Search

brazos RFP 209-028 Hand Held Ticket Writer System 84 User The System should eliminate All of our systems are build with the intention of minimizing Expected Interface redundant data entry and retain data entry time and errors. For example, if the officers data when users navigate complete an accident report with 2 people and 2 vehicles, between screens and Systems. that information can be imported into the citation and/or tow report application without having to re-enter any information. 85 User The System should be able to use Citations are printed from the MC75 to the Zebra printer via Expected Interface wireless technology to print. Bluetooth. Each device is associated with a printer by scanning the barcode on the printer. Once the device is associated with the printer, the device will only print to that printer until it is associated to another printer. There is no limit to the number of devices that can be associated to one printer. 86 User The System should be able to use Currently, our system does not utilize the infrared port to Expected Interface infrared technology to print. print to the printers. This is because the Zebra printers do not have infrared capabilities. 87 User The System should enable Each of the hardware buttons on the device, except standard Desired Interface Administrators to assign function OWERTY keyboard functions, can be associated with events keys to common tasks. or applications providing user defined shortcuts within the application. User In terfaceErrors Item ,# Category Requirement Description Required Response Priori 88 Interface The System should produce error Data validation rules are enforced when the officer tries to Expected Errors messages (i.e. user enters text in print or save a record. The error is presented to the officer a numeric field). and then the officer is taken to the offending field for completion. 89 Interface Error messages should be able to The City can define and/or modify any error message Expected Errors be created and modified by the presented to the user. City Administrator. Business Continui ty Item # Category Requirement Description Required.Response Priori 90 Business The Proponent should provide The size requirements of the server will depend upon the Expected Continuity archival capacity estimates (in number of devices (which is not stated in the RFP) as well as terms of GB of storage) for the the projected number of tickets stored, whether the City system proposed. wants video, and the additional applications desired by the City. Our initial recommendation would be to have no fewer than three 72GB hard drives in a RAID 5 configuration which would amount to 144GB of storage space for both the database and web servers. This will allow up to 2 more 72GB hard drives in the future for further expansion. Of course, if the City elects to utilize a SAN, these requirements can be reduced. Item # Category Requirement Description Required Response Priori 91 Business The System should include a The Brazos system allows users (with proper access) to Expected Continuity method to delete a record and all delete records, but those records are only marked for associated child records. deletion and can be recovered by an administrator. We currently do not actually delete any records, we just don't report on the ones marked for deletion. Hard deletes (where they are removed completely from the system) are only performed by Administrators and include all child records. 92 Business The System should include a The current method for purging data is at the Administrator Expected Continuity method of purging archived data level by running scripts directly on the database. We have from the production database(s). elected to not have any full deletes or purges via the eCitation server interface in order to prevent any accidental data removal.