RMS_Capability_Workbook.xlsx
XLSX spreadsheet 48 KB Posted
- Attached to
- Law Enforcement Computer Aided Dispatch (CAD) and Records Management System (RMS) COTS Software Tool
- Solicitation number
- FRB-18-002
About this file
Attachment RMS Capability Workbook
View the file
Other files
| File | Type | Posted |
|---|---|---|
| CAD_RMS_Functionality_Workbook.xlsx | XLSX spreadsheet | |
| Market_Survey_FRB-18-002-_LEU_CAD_RMS_Software_Tool.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
INSTRUCTIONS
RMS
| RMS CAPABILITY WORKSHEET | ||||
| ID | Specification Description | Priority MH =Must Have HP=High Priority LP=Low Priority | Response Code (EF, UD, TP, C,NA) Existing Functionality Under Development Third Party Customization Not Available | Vendor's Comments (Optional) |
| 1 | Master Name Index: The RMS Master Name Index (MNI) creates an individual master name record for every individual who is involved in, or associate with, the following: | HP |
| 1.2 | Incident reports | HP |
| 1.3 | Arrest reports | HP |
| 1.4 | Field interviews | HP |
| 1.5 | Misc Reports | HP |
| 1.6 | Citations | HP |
| 1.7 | Property/evidence reports | HP |
| 2 | MNI Correlation: The master name record is linked to all events for any given individual, so that by querying that one name, the system will produce a synopsis of all the involvements associated with that one person. | HP |
| 3 | MNI Linkage: The MNI also facilitates the linking of additional names to an individual master name record (i.e., alias information and relationship data). In querying an individual MNI record, the user will be able to view all related records, as well as those associated with that individual. | HP |
| 4 | Duplicate Correction and Correlation: When a record or report is added to RMS and a person is linked (i.e., indexed) to that event, the system will search for duplicate identities within the MNI. The user will be presented with a list of possible matches to the name so that the user has the option to link the records. Once the list of possible matches is provided, the user has the option to decide whether the information will be linked to an existing master name record or whether a new master name entry will be added. The RMS provides a matching algorithm that will provide the ability to search the name file by the following criteria: | HP |
| 4.1 | Sound-alike searching | HP |
| 4.2 | Phonetic replacement | HP |
| 4.3 | Diminutive first names (e.g., James/Jim/Jimmy, Elizabeth/Beth/Betty, and Jack/John) | HP |
| 4.4 | Other static demographic information, such as age, sex, and race. | HP |
| 5 | Master Vehicle Index (MVI): The system should provide a centralized source of vehicle information. | HP |
| 6 | MVI Entry and Matching: When a vehicle is entered into the system, the system should search for a match in the MVI. If a match is found, the system should display to the user a list of events to which the vehicle is linked. The user should be able to select from the list of events to see the details of a specific event or to see a summary of all events that involve the vehicle. If no match is found in the MVI (i.e., if the vehicle is not already in the MVI), the system should add the vehicle's information to the MVI and link it to the appropriate event(s). | HP |
| 7 | MVI Data Elements: The system should store the following information in the MVI for each vehicle: | HP |
| 7.1 | Vehicle Identification Number (VIN) | HP |
| 7.2 | License plate number | HP |
| 7.3 | License plate state | HP |
| 7.4 | License plate year | HP |
| 7.5 | Registered owner | HP |
| 7.6 | Description (e.g., make, model, year, color, style, and attributes) | HP |
| 8 | Master Property Index (MPI): The system should provide a centralized repository for property information. | HP |
| 9 | MPI Master Category: Each piece of property entered into the system should be associated by a master category or type of evidence such as drugs, weapons, electronic goods. | HP |
| 10 | MPI Data Elements: Each piece of property entered into the system should be identified by: make, model, brand, description, distinguishing characteristics, and serial number. | HP |
| 11 | MPI NCIC Compliance: The system should use NCIC property codes to correctly identify each property item. | HP |
| 12 | MPI Entry and Matching: When a new piece of property is entered into the system, the system should identify existing records in the MPI that have the same or similar characteristics and present the list of potential matches to the user. | HP |
| 13 | Master Location Index: (MLI) The Master Location Index (MLI) provides a means to aggregate information throughout RMS based on the following: | HP |
| 13.1 | A specific address | HP |
| 13.2 | A range of addresses | HP |
| 13.3 | An area | HP |
| 13.4 | Locations based on x/y/z coordinates | HP |
| 13.5 | Registered owner | HP |
| CALLS FOR SERVICE REPORTING | ||
| 14 | Service Report Functionality: The following calls for service reports should be provided: (could include ability to produce reports using reporting tools): | HP |
| 14.1 | Daily log showing all calls received for the prior 24 hours from prior printing of the daily log (by user defined department) | HP |
| 14.2 | Activity analysis by specified geographical area and time period | HP |
| 14.3 | Activity analysis by day of week | HP |
| 14.4 | Activity analysis by hour of day | HP |
| 14.5 | Activity analysis by day and hour | HP |
| 14.6 | Workload activity by resource assigned | HP |
| INCIDENT REPORTING | ||
| 15 | Incident Reporting: The following incident-report-related reports should be provided: | HP |
| 15.1 | All summary UCR reports | HP |
| 15.2 | Total incident reports based on period of time, area and incident type | HP |
| 15.3 | Location code (e.g., geocode) | HP |
| 15.4 | Initial call type | HP |
| 15.5 | Offense type | HP |
| 15.6 | Summary of incidents by a responsible officer | HP |
| 16 | Prepare Initial Incident Report: The incident report contains factual information pertaining to the incident, including the following: | HP |
| 16.1 | Offense information | HP |
| 16.2 | Suspect information | HP |
| 16.3 | Case status | HP |
| 16.4 | Information pertaining to perpetrators | HP |
| 16.5 | Witnesses | HP |
| 16.6 | Victims | HP |
| 16.7 | Complainants | HP |
| 17 | Free Fields: Incident reports have free-text fields, which allow the collection of a virtually unlimited amount of narrative information. | HP |
| 18 | Searchability: The system provides the capability to search the narratives for a specific word or phrase. | HP |
| 19 | Electronic Submission: Once completed, officers may submit the incident report to their supervisor for review, electronically, via the RMS. | MH |
| 20 | Create Supplemental Report: The system provides supplemental reports that are linked to the original, including certificate of release and probable cause declaration. | HP |
| 21 | Report Review: The incident report should be able to be locked from further edits at a point determined by the FRB/LEU (although this does not preclude the viewing of the document by those with access permissions, but the ability to block access will be a capability of the system). | HP |
| 22 | Supervisory Review: Supervisors review incident reports and supplemental reports for accuracy and quality prior to their permanent, non-editable storage in the RMS database. | HP |
| 23 | Electronic Supervisor Review: RMS should allow supervisors to receive, review, and approve incident reports online and to electronically respond to submitting officers and investigators regarding report quality and accuracy issues. | HP |
| 24 | Report Locking: The system supports all required reviews and corrections prior to locking down the incident report. | HP |
| PROPERTY AND EVIDENCE | HP | |
| 25 | Property and Evidence Management: The following property and evidence management reports should be provided: | HP |
| 25.1 | Chain of custody | HP |
| 25.2 | Property summary report | HP |
| 25.3 | Property item detail | HP |
| 25.4 | Released property report | HP |
| 25.5 | Property inventory report | HP |
| 25.6 | Property disposition reports | HP |
| 25.7 | Form letter to inform the property owner of the pending disposition of property with instructions for filing a claim | HP |
| 25.8 | Evidence location summary report | HP |
| 26 | Collect Property and Evidence: The system provides data entry screens to allow users to enter information on property and evidence that has been received, The system should capture the following information for chain of evidence purposes: | |
| 26.1 | Original officer | |
| 26.2 | Person checking property out | |
| 26.3 | Person checking property in | |
| 27 | When a piece of evidence is entered into the system, the system should search the MPI to identify potential matches and should present the list of potential matches to the user. | |
| 28 | Property and Evidence Storage: The system should provide a check-in/check-out log to allow property movement to be tracked. | HP |
| 29 | Property and Evidence Disposition: The RMS includes safeguards to ensure that procedures and laws governing the release, sale, or destruction of property are followed. | HP |
| 30 | Disposition Event Messaging: The system will use automated messaging for specific property/evidence-related events that require notification (for release, destruction, adjudication). | HP |
| 31 | Property Imaging: The system provides a means to store digital images of the item prior to the disposition. | HP |
| 32 | Property Disposition Alerts: The system will generate automatic alerts to pre-defined email addresses when property is eligible for release or sale. | HP |
| ARREST REPORTS | HP | |
| 33 | Arrest Reports: The following arrest reports should be provided: | HP |
| 33.1 | Daily arrests, by day and time, date range and geographic areas | HP |
| 33.2 | Arrest report and/or affidavit | HP |
| 33.3 | Arrests by location and time period | HP |
| 33.4 | Arrest log by time, and location | HP |
| TRAFFIC REPORTING | HP | |
| 34 | Traffic Reporting: The following traffic related reports should be provided: | HP |
| 34.1 | Accident Report Forms | HP |
| 34.2 | Accidents by location | HP |
| 34.3 | Accidents by violation | HP |
| 34.4 | Accidents by driver demographic | HP |
| 34.5 | Statistics by location, day, and time | HP |
| 35 | Accident Reporting: The system should provide drawing or diagramming tools to allow the RMS users to diagram accident report data | HP |
| 36 | The accident reporting system should allow the user to attach accident diagrams and photos to a specific event | |
| 37 | The accident report system should provide a data entry screen to allow the user to enter traffic accident data including: | |
| 37.1 | weather | |
| 37.2 | visibility | |
| 37.3 | road surface conditions | |
| 37.4 | location information | |
| CITATIONS | HP | |
| 38 | Citation Reporting: The following citation-related reports should be provided: | HP |
| 38.1 | Citation and warnings summary based on varying search criteria | HP |
| 38.2 | Citation by location | HP |
| 39 | Issue Citation: Citation information should be stored and tracked in RMS to include: | |
| 39.1 | subject's information | |
| 39.2 | vilolation | |
| 39.3 | date, time | |
| 39.4 | location of violation | |
| 40 | Citation information should be capable of being sent, electronically to the parking unit and/or DC Gov't | |
| 41 | Citations and warning should be linked to the subject's master name record | |
| FIELD INTERVIEW | HP | |
| 42 | Field Contact Reports: The following field contact-related reports should be provided: | HP |
| 42.1 | Field Interview Form (to enter information from FI Cards) | HP |
| 42.2 | Field contact summary, based on varying search criteria | HP |
| 42.3 | Document Field Contact: The system should provide a data entry screen to allow the user to document a field contact. The system will provide field contact templates to capture pertinent information for the following types of contacts: | HP |
| 42.4 | A parked car in an area and at a time normally vacant of cars | HP |
| 42.5 | One or more people in an area and at a time normally vacant of people | HP |
| 42.6 | One or more people loitering in a vulnerable area | HP |
| 42.7 | People and vehicles that appear to be out of place for any particular reason | HP |
| CRIME ANALYSIS | HP | |
| 43 | Crime Analysis: RMS has a variety of reporting functions attached to their Analytical Support modules and allows presentation of information in a variety of formats, such as bar graphs, pie charts, and line graphs | HP |
| 44 | Crime Analysis Features: RMS supports the ability to aggregate data on the various indicators, such as: | HP |
| 44.1 | Current period vs. previous period | HP |
| 44.2 | Current period vs. historical average | HP |
| 45 | Percentage of Total Crime Reports: Percentage of total crimes for period by change from prior periods (i.e., trend) | HP |
| 46 | Crime Distribution: RMS contains the ability to conduct crime distribution analysis based on a number of criteria, including: | HP |
| 46.1 | By time, date, and day of week | HP |
| 46.2 | Frequency of occurrence | HP |
| 46.3 | Citation | HP |
| 46.4 | Crime/incident report number | HP |
| 46.5 | Field interview data | HP |
| 46.6 | Vehicle information | HP |
| 46.7 | Type of offense | HP |
| 47 | Additional Crime Analysis Reports: The Crime Analysis module provides the following reports: | HP |
| 47.1 | General offense activity | LP |
| 47.2 | Offense activity by day of week | LP |
| 48 | Crime Analysis Searchability: Every field of operational data in RMS (i.e., data entered by the user in any form, not configuration or system control data) will be searchable, including narrative (e.g., text or memo) fields: | HP |
| 48.1 | This is accomplished by using query interfaces that are part of the application or, at a minimum, using third-party tools that can access the operational database via Open Data Base Connectivity (ODBC) | |
| 49 | Correlation: RMS supports crime/suspect correlations to show a relationship between a suspect and an offense. The correlations may be made by using any number of selected criteria: | |
| 49.1 | unique and distinguishing characteristics | |
| 49.2 | phsyical identifiers | |
| 49.3 | modus operandi | |
| 50 | These identifiers are captured as a part of multiple different business functions: | |
| 50.1 | field contact | |
| 50.2 | arrest | |
| 50.3 | accident | |
| 50.4 | citation | |
| 50.5 | BOLO Information | |
| 51 | Online Dashboard: RMS supports a dashboard that allows agencies to share relevant crime statistics directly with the appropriate entities within the Board. | HP |
| 52 | Online dashboards allow end-users to conduct searches based on user-defined parameters (i.e., periods of time, location, and incident types). | HP |
| REPORTING | HP | |
| 53 | Standard RMS Reporting: Law enforcement personnel should be able to generate standardized reports and aggregate reports, as well as query RMS to produce ad hoc reports from the RMS reports module. Examples of standardized reports from RMS business functions are: | HP |
| 53.1 | Incident reports | HP |
| 53.2 | Accident reports | HP |
| 53.3 | Property/evidence reports | HP |
| 53.4 | Citation reports | HP |
| 53.5 | Field interview reports | HP |
| 53.6 | Uniform Crime Reports (UCR) | HP |
| 53.7 | Case management reports | HP |
| 53.8 | Summary reports for citations, and accidents | HP |
| 54 | Aggregate Reporting: Aggregate, agency-wide reporting allows law enforcement personnel to associate information in a variety of ways and among a number of different tables or fields, including: | |
| 54.1 | incident data | |
| 54.2 | property data | |
| 54.3 | weapons data | |
| 55 | Ability to query on indicators: | |
| 55.1 | date of incident | |
| 55.2 | case type | |
| 55.3 | assigned officer | |
| 56 | Ability to produce reports from a list of standard reports | |
| 57 | Standardized Reporting: Each module includes its own set of standardized reports, which also are available through the RMS Incident Reporting module. | HP |
| 58 | Ad Hoc Reporting:LEU may need operational reports and analysis that are not provided by standard RMS reports and queries. Ad hoc reporting will allow LEU to define and create these additional custom reports. | HP |
| 59 | Created ad hoc reports can be saved and run as standard reports | |
| 60 | Able to product unlimited number of ad hoc reports | |
| INVESTIGATIVE CASE MANAGEMENT | HP | |
| 61 | RMS System Administrators should be able to define Investigative Case Management module parameters (e.g., case assignment, case management, monitoring, and control) without requiring any assistance from the RMS vendor. | HP |
| 62 | Authorized RMS users should be able to enter case activity and other case related information via a combination of validated fields and free format text fields (e.g., narrative fields) that are contained in predefined Investigative Case Management module supplemental report forms and data entry screens. | HP |
| 63 | The Investigative Case Management module should support an investigative supplemental report approval process. | HP |
| 64 | The Investigative Case Management module should link investigative case activity to initial offense and supplemental reports. | HP |
| 65 | Investigative Case Management cases should be composed of the initial offense and any associated supplemental reports, property and evidence records, arrest reports, witness statements, and other various associated files and data. | HP |
| 66 | RMS System Administrators should be able to set up and maintain case solvability logic that computes the solvability of a case based on information contained within the case (e.g., availability of witness information, method of operation, location, elapsed time, and other factors) without requiring any assistance from the RMS vendor. | HP |
| 67 | The Investigative Case Management module should support automatic report routing of completed and/or approved reports based upon the information contained in the report (e.g., offense type, report priority, solvability factors, etc.). | HP |
| 68 | RMS System Administrators should be able to set up and maintain report and case routing parameters that cause the RMS to automatically route completed and approved reports to designated users, groups of users, and/or supervisory role positions of organizational units defined within the RMS without requiring any assistance from the RMS vendor. | HP |
| 69 | The RMS should notify recipients (designated users, user groups, and/or supervisory role positions defined within the RMS) of automatically routed reports that a new or rerouted/reassigned report has been routed to them. | HP |
| 70 | Authorized RMS users should be able to change the offense type of a report thereby causing the report to be re-routed to an appropriate set of users, user groups, and/or supervisory roles. | HP |
| 71 | RMS System Administrators should be able to set up report routing parameters that cause a single, completed/approved report to be routed to multiple destinations (multiple users, user Groups, and/or supervisory roles) based on information contained within the report and its location without requiring any assistance from the RMS vendor. | HP |
| 72 | Authorized RMS users should be able to change the organizational unit responsible for investigating a report and case. | HP |
| 73 | The RMS should notify the organizational unit responsible for investigating a report and case if the responsible organizational unit for the report and case is changed. | HP |
| 74 | The original organizational unit responsible for investigating a report/case should approve any changes in the responsible organizational unit for that report/case. | HP |
| 75 | The Investigative Case Management module should provide an interactive means of assigning reports and cases to investigators, monitoring investigative case progress, and initiating case dispositions. | HP |
| 76 | The Investigative Case Management module should be able to track a case from its assignment to an investigator through final disposition. | HP |
| 77 | The Investigative Case Management module should track the detail/division, individual, and the date and time that a case was reviewed. | HP |
| 78 | The Investigative Case Management module should allow investigative supervisors to view detailed case information and other case related activities of their subordinates. | HP |
| 79 | The Investigative Case Management module should provide the ability for investigators to enter case dispositions and statuses (e.g., clear a case by arrest, etc.) in an interactive format. The module should require that changes of disposition or statuses be approved by a supervisor. | HP |
| 80 | Authorized RMS users should be able to select a number of reports and cases and to update all of the selected reports and cases in one action (e.g., assign multiple cases to a single investigator, update the status of multiple cases with a single command, etc.). | HP |
| 81 | The display of reports and cases to be monitored and assigned by the Investigative Case Management module should be controlled by the organizational unit. The default display of reports and cases to be assigned by a specific user or investigative supervisor should only include the cases within that user's organizational unit. | HP |
| 82 | The Investigative Case Management module should provide for an online investigative case journal. | HP |
| 83 | The Investigative Case Management module should notify appropriate supervisory personnel if a case has exceeded the assigned time interval for a status update or change in status for the particular case type. | HP |
| 84 | RMS System Administrators should be able to assign and maintain report and case status time interval parameters, without requiring any assistance from the RMS vendor. when the status time interval has been exceeded should cause a notification to be sent to a designated set of users, user groups, and/or supervisory role positions defined within the RMS. | HP |
| 85 | The Investigative Case Management module should notify investigative personnel of other RMS activities and transactions affecting their assigned reports and cases. | HP |
| 86 | The Investigative Case Management module should be fully integrated with the Offense and Supplemental Reports module and provide access to all initial offense and supplemental reports in a case, as well as involved individuals such as suspects, victims, witnesses, etc. | HP |
| 87 | The Investigative Case Management module should provide access to the charges, narrative, property, vehicles, and all other information available in the initial offense and supplemental reports of a case. | HP |
| 88 | The Investigative Case Management module should include a case summary function or database that provides a quick way to determine the latest status of the elements of a case without having to sort through the various reports of the case. If the initial report described the color of an involved vehicle as red and after further investigation the vehicle color was updated (via a supplemental report) to be blue, the case summary function should identify the vehicle's color as blue. The initial offense report would still identify the vehicle's color as red. However, the supplemental report would indicate when it was changed to blue and why. The status of involved persons would also change as dictated by the various reports constituting the case (e.g., an initial witness may, after further investigation, be found to be a suspect and eventually arrested). The case summary function would always display the most current status of involved persons. | HP |
| 89 | Authorized RMS users should be able to query the Investigative Case Management module by, but not limited to the following criteria: date and time range, assigned investigator, case type, investigative division/detail, case status, location, and various combinations of all of these selection criteria. | HP |
| 90 | Investigative Case Management module query responses should display a list of reports and cases that meet the selection criteria. | HP |
| 91 | Authorized RMS users should be able to obtain additional report and case details by selecting one or more of the reports and cases listed in response to a Investigative Case Management module query. | HP |
| 92 | The Investigative Case Management module should provide reports on case status summary (case closing analysis) by division/detail, and/or organizational unit. | HP |
| 93 | The Investigative Case Management module should provide reports on assigned cases (Officer workload) by division/detail, and/or organizational unit. | HP |
| 94 | The Investigative Case Management module should provide reports on division/detail, and/or organizational unit case counts. | HP |
| 95 | The Investigative Case Management module should provide reports on case activity summary (electronic logbook) by division/detail, and/or organizational unit. | HP |
| 96 | The Investigative Case Management module should provide follow-up due reports by division/detail, and/or organizational unit. | HP |
| 97 | The Investigative Case Management module should support statistical analysis and management reports regarding individual Officer and division/detail productivity, by combining case activity and case journal entries between a user-specified date and time range, as well as by user-specified division/detail, and/or organizational unit. | HP |
| 98 | Case activity journals within the Investigative Case Management module should include predefined categories of investigative actions that should be maintainable by RMS System Administrators without requiring any assistance from the RMS vendor. | HP |
| 99 | The Investigative Case Management module reports should include appropriate charts to display actual time and percentage calculations of investigative activities based upon various investigative categories. | HP |
| 100 | The Investigative Case Management module should be able to store a (practically) unlimited number of various printed documents and pictures (including videos) such as offender and witness statements, lab reports, evidentiary documents, etc., and the attachment of those documents, videos and files to case records. | HP |
| 101 | The Investigative Case Management module should allow the use of digital media for the recording of crime scenes or other photographic, video or audio evidence and the attachment (linkage) of a practically unlimited number of evidentiary images to individual reports within cases. | HP |
| 102 | Access to reports and associated data, diagrams, and images within the Investigative Case Management module should be controlled according to the security requirements specified in this RFP. | HP |
| 103 | The Investigative Case Management module should be relationally cross-referenced to the Offense and Supplemental Reports, Report Approval, and other appropriate RMS modules, as well as the master indexes. | HP |
| 104 | Authorized RMS users should be able to use the Investigative Case Management module to create tip sheets and/or crime intelligence bulletins. | HP |
| 105 | Authorized RMS users should be able to package a complete case file with the press of a button. This function should allow incident and supplement reports, property, videos, and all linked RMS data to be printed to a PDF. This file along with all attachments should then be saved to the users destination of choice. | HP |
| 106 | The Investigative Case Management module should allow users to link all related cases together. | HP |
| 107 | The ability to set reminders regarding items such as follow-up tasks, expiration dates, and required activities. | HP |
| RMS SYSTEM ADMINISTRATION | ||
| 108 | General RMS Maintenance: The RMS system administration functions address RMS configurable aspects. System administration encompasses a wide array of general functions that law enforcement agencies need from their RMS to be able to create and query information effectively; ensure appropriate access to information and systems security; and ensure effective departmental information, image, and document management. Required administrative functions include. | HP |
| 108.1 | RMS table maintenance | HP |
| 108.2 | RMS configurations (parameters, defaults) | HP |
| 108.3 | Security (user role, jurisdiction) | HP |
| 108.4 | Geofile management | HP |
| 108.5 | Data management (data dictionary, archive and purge) | HP |
| 108.6 | Report on users, sortable by names, access level, password age, and machine used | HP |
| 108.7 | Report on RMS usage, sortable by user log-in, frequency, total time in system, number of concurrent log-ins, machine used, and duration time-outs | HP |
| 108.8 | Report on failed log-ins, sortable by log-in name, number of attempts, date/time of attempt, and machine used | HP |
| 108.9 | Report on subsystem security violations | HP |
| 108.1 | User-definable security alerts, which generate an external message to predefined locations | HP |
| 109 | Table Maintenance: RMS includes the ability for the LEU to define and maintain codes and associated literals (i.e., plain English translation). The literals will be stored in the database. | HP |
| 110 | Record Disposition: RMS should be able to support expungement, sealing, and purging of whole records and partial records. To support this function, the system should be able to flag a record, flag data elements within a record, and delete a record. The flag indicates why the record or data element is restricted. | HP |
| 111 | Data Redaction: In the case of formatted and structured data, report output programs produce redacted versions of specific report data. In the case of narrative or otherwise unstructured information, the redaction process requires a manual step to produce public version of the report. Relying on Adobe PDF tools, or other manual tools, to achieve this functionality would not be acceptable. | HP |
| 112 | Data Dictionary: RMS should provide a capability to display and/or print the database structures to allow LEU to access the database tables through third-party, ad hoc inquiry tools/ utilities. | HP |
| 113 | Data Dictionary Field Descriptors: The data dictionary may contain the following information for each field description: | HP |
| 113.1 | Field name (external representation) | HP |
| 113.2 | Database column name (internal representation) | HP |
| 113.3 | Data type (numeric, alpha, or date) | HP |
| 113.4 | Field size | HP |
| 113.5 | Field format (output format) | HP |
| 113.6 | Edit or validation criteria | HP |
| 113.7 | Associated code table | HP |
| 113.8 | Default value | HP |
| 113.9 | Description | HP |
| 114 | General Geofile Maintenance: The system allows LEU to enter and update all geofile data, including the physical address and the x/y/z coordinates. | HP |
| 115 | Geofile Database Maintenance: The system supports the creation and maintenance of the geofile using an available mapping/ Geographic Information System (GIS) database. | HP |
| 116 | Geofile Synchronization: Geofile information in CAD and RMS will be synchronized, based on LEU-established parameters. | HP |
| 117 | RMS Configuration Warning: Any configuration changes that could affect system integrity should be properly flagged with adequate warning to prevent inadvertent damage to the system. | HP |
| 118 | Training Environment: This function relates to the necessity of having a training environment on the RMS system that is isolated from the production and testing environments for the purposes of program testing and file maintenance testing, as well as training of new personnel. To the greatest extent possible, the training environment will be identical to the production region, thus allowing accurate testing and training to occur without impacting the production environment. | HP |
| 119 | Attachments: Ability to store attachments/media to store in location other than RMS | HP |
| 120 | Ability to lock/unlock a user in RMS. | HP |
Microsoft_Word_Document1.docx RMS Worksheet Instructions
Respondents should review each requirement in the worksheet and assign a Response Code (RC) that reflects the capability of their applications to meet the requirement. Please include one of the following Response Codes for each listed requirement in the column captioned Response Code:
· "EF" - Existing Functionality: Item will be met by proposed existing software that is installed and operational at other sites. An “EF” response to any item signifies that the proposed system provides the actual capability to meet the criteria as a Core feature, without additional cost and without extensive user intervention. Indirect or implied solutions to meet the criteria shall not be coded “EF”.
· “UD” - Under Development: Item will be met by software that is currently under development, in beta test, or not yet released. Provide target date for future release.
· "TP" - Third Party: Item will be provided through a third-party solution partner, utilizing a solution or interface that has been implemented successfully elsewhere.
· “C”-Customization. This item would require customization by vendor to meet requirements. Customization is defined as altering the code of the proposed system, so it is no longer considered a COTS system.
· "NA" - Not Available: Requirement cannot be provided.
· Vendor comments are optional, but encourage especially for any item not marked EF image1.emf
File details come from the government source that posted it.