The file's text, extracted by GovTribe without its formatting.
CONTENTS
| 1. | INTRODUCTION | 1 |
| 2. | purpose | 1 |
| 3. | vendor response instructions | 1 |
| 4. | REQUIREMENTS | 3 |
| 4.1 | General Requirements | 3 |
| 4.2 | Static Data Management Requirements | 4 |
| 4.3 | Sample Processing Requirements | 5 |
| 4.4 | Test Processing Requirements | 8 |
| 4.5 | Report Requirements | 11 |
| 4.6 | Label Requirements | 14 |
| 4.7 | Storage Location Management Requirements | 15 |
| 4.8 | Consumable Management Requirements | 15 |
| 4.9 | Instrument Management Requirements | 16 |
| 4.10 | Analyst Certification Requirements | 17 |
| 4.11 | Customer Billing Requirements | 18 |
| 4.12 | Client Portal Requirements | 19 |
| 4.13 | Interface Requirements | 20 |
| 4.14 | Electronic Signature Requirements | 22 |
| 4.15 | Electronic Record and Audit Trail Requirements | 22 |
| 4.16 | Security Requirements | 23 |
| 4.17 | Infrastructure, Implementation and Support Requirements | 25 |
| 5. INTERFACE DETAILS | 27 | |
| 6. DATA VOLUME | 30 | |
1. INTRODUCTION
The goal of the U.S. Geological Survey (USGS) Water Mission Area laboratories is to support USGS programs by producing and reporting data of known, documented and traceable quality. The laboratories are required to utilize a quality system that is compliant with governing agencies.
To achieve this goal with ultimate operational efficiency and compliance, the USGS is seeking a Laboratory Information Management System (LIMS) that is capable of handling current and future production loads of the National Water Quality Laboratory, the Reston Stable Isotopes Laboratory, the Reston Groundwater Dating Laboratory, the Menlo Park Tritium Laboratory as well as additional production and research laboratories that will be added at a later date.
There is an existing LIMS currently in place. It is highly customized, error prone and is no longer supported by the vendor, hence the need for a replacement.
1. purpose This document defines the requirements of the system for the purpose of soliciting a response from vendors of LIMS products. Refer to the sections in the table below, where each requirement is uniquely identified and logically organized based upon workflow and functional area of the system. For each, detailed descriptions are provided as are references to more indepth user story narratives which are documented in Reference 1: ‘U.S. Geological Survey Water Mission Area User Stories for LIMS’.
| 5.2 |
| Static Data Management Requirements |
| 5.3 |
| Sample Processing Requirements |
| 5.4 |
| Test Processing Requirements |
| 5.7 |
| Storage Location Management Requirements |
| 5.8 |
| Consumable Management Requirements |
| 5.9 |
| Instrument Management Requirements |
| 5.10 |
| Analyst Certification Requirements |
| 5.11 |
| Customer Billing Requirements |
| 5.12 |
| Client Portal Requirements |
| 5.13 |
| Interface Requirements |
| 5.14 |
| Electronic Signature Requirements |
| 5.15 |
| Electronic Record and Audit Trail Requirements |
| 5.16 |
| Security Requirements |
| 5.17 |
| Infrastructure, Implementation and Support Requirements |
1. vendor response instructions Vendors are requested to respond to this document by reviewing each requirement and defining how their solution is capable of meeting it.
Responses to requirements in Sections 5.1 to 5.16 will use one of four implementation strategies as defined in the following table. Vendors are asked to further define custom solutions as to their degree of complexity by assigning a value from 1 to 5, where 1 is a low degree of complexity and 5 is a high degree of complexity. While it is acknowledged that specific design requirements are not yet provided, the vendor is requested to use their experience to approximate this rating.
| Implementation Strategy |
| Description |
| Base |
| The requirement is met with base product functionality and no vendor configuration. |
| Configured Base |
| The requirement is met with base product functionality and vendor configuration. |
| Custom |
| The requirement is met with a custom solution developed by the vendor. |
| None |
| The requirement cannot be met. |
Responses to requirements in Section 5.17 will be yes, no or n/a, accompanied by a detailed written response.
| 140G0223R0001 LIMS Solution | Attachment A – Requirements for Vendor Response |
| 140G0223R0001 LIMS Solution | Attachment A – Requirements for Vendor Response |
1.
1. REQUIREMENTS
General Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support the use of queries. |
| The system must provide one or more query for each workflow function, where each query provides a logical and intended set of filtered objects to process for a specific purpose. |
| 27, 46, 78, 170, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to sort the results of a query. |
| 9, 27, 46, 170, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support different data types and formats. |
| The system must support the use of a text data type. |
| 59 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the use of an integer data type and allow the entry and display of one or more leading zeros. |
| 59 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the use of a decimal data type and allow the entry and display of one or more leading zeros. |
| 59 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the use of a date data type. |
| 59 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the use of a date/time data type. |
| 59, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must enforce a predefined format during data entry. |
| 59 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support different data entry modes. |
| The system must support manual data entry. |
| 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support data entry by selecting from a predefined selection list. |
| 59, 192, 210 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the use of default values. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the overwriting of display only fields. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must enforce mandatory field entry. |
| 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must display system and session information. |
| The system must display the currently installed software version |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must display the user account that is currently logged in. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide an online help facility. |
| 118 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must present user functions via a dashboard display. |
| 103, 165, 166 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Static Data Management Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support the creation of static data. |
| The system must support the creation of the following static data elements, including but not limited to: |
· Accounting Codes
· Analytes
· Analytical Status Codes
· Chemical Abstract Service (CAS) Numbers
· Clients
· Contacts
· Definitions for Calculations
· Detection Limits
· External Testing Laboratories (Proto Org Table)
· Field Sampling Protocols
· Field Supply Part Numbers
· Laboratory Codes
· Locations
· Materials
· Matrix Codes
· Method and SOP Citations
· NWIS Parameter Codes/Method Codes
· Per Analyte Method Performance Metrics
· Price List
· Release Status Codes
· Reporting Limits
· Sample Containers and Acceptable Alternates
· Sample Hold Times
· Sample Types
· Shipping Protocols
· Specifications
· Storage Areas
· Tests
· Users
· Vendors
| 13, 44, 64, 66, 67, 68, 101, 125, 128, 153, 155, 176, 179, 180, 189, 191, 192, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the management of static data. |
| The system must support the viewing of static data. |
| 60, 101, 123 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the modification of static data and enforce the entry of a reason. |
| 44, 66, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the modification of static data in batch mode. |
| 44, 66, 189, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the modification of static data by more than one user at a time. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the versioning of static data. |
| 60 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the expiration of static data. |
| 109 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the deletion of static data. |
| 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support different static data approval procedures. |
| The system must support and enforce peer approval of static data. |
| 67 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support non-peer approval of static data. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support no approval of static data. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the ability to update static data from an external authoritative source (RLMS). |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
Sample Processing Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support the creation of a sample. |
| The system must support the login of a sample using a predefined sample template. |
| 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the login of one sample at a time. |
| 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the login of multiple samples at a time. |
| 129, 130, 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the manual and automatic login of samples from an Analytical Service Request (ASR) or electronic Analytical Service Request. |
| 129, 130, 189, 190 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the login of parent-child samples. |
| 175 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the login of a sample prior to its arrival in the laboratory. |
| 189, 190 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the login of a sample at the time of its arrival in the laboratory. |
| 25, 22 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically generate a unique sample ID of a predefined format. |
| 174, 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically generate a unique identifier that links the sample bottle (Analytical Service Request Lab ID) to sample header information. |
| 189, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry of sample information that is specific to the sample type. |
| 25, 57, 60, 78, 123, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the browsing of a static data table and the display of descriptive information during the entry of sample information, including but not limited to QC codes. |
| 150 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow a sample to be flagged for internal or external reporting. |
| 221 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow a sample to be flagged as a rush sample. |
| 36, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must send an alert when a sample is flagged as a rush sample. |
| 96 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow a sample to be flagged as requiring chain of custody. |
| 92 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must send an alert when a sample is flagged as requiring chain of custody. |
| 92 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow a sample to be flagged as a blind sample for the purpose of expedited result transmittal to the client but hidden from everyone except for select people (LASD business analyst). |
| 148 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the manual and automatic assignment of test(s) to a sample at the time of sample login. |
| 44, 63, 101, 162, 163, 189, 202 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must display the required sample amount based upon the selected test(s). |
| 176 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the attachment of a file to a sample. |
| 192, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide sample life cycle management. |
| The system must support a sample life cycle that is specific to the sample type. |
| 122 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the automation of select life cycle steps based upon sample type. |
| 184 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically capture the user ID, date and time for steps in a sample life cycle. |
| 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically track the status of a sample throughout its life cycle. |
| 122 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the status of a sample to be displayed. |
| 102 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must update the status of a sample based upon the status of its assigned tests. |
| 62, 64, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the manual entry of a sample ID or the scan of a sample barcode label during workflow processing. |
| 174, 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support a logical grouping of samples based upon a unique project and/or Analytical Service Request. |
| 17, 23, 129, 192, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the prioritization of samples based upon information including but not limited to hold time or rush status. |
| 74 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the execution of events based upon predefined sample triggers. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the modification of a sample. |
| The system must allow sample information to be modified and enforce the entry of a reason. |
| 32, 156, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the modification of a sample following its approval without complete traceability and documentation. |
| 32 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the receipt of a sample. |
| The system must support the receipt of one sample at a time. |
| 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the receipt of many samples at a time. |
| 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the receipt of a sample to be bypassed, based upon sample type. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the approval of a sample. |
| The system must support the approval of a sample and the assignment of a final disposition. |
| 65, 88, 89 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a predefined selection list of sample dispositions. |
| 136, 140 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry of a comment at the time of sample approval. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the approval of a sample prior to the entry and review of all tests assigned to it. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the display of test results at the time of sample approval. |
| 65 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to un-approve a sample and enforce the entry of a reason. |
| 143 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support additional sample functions. |
| The system must support the submission of a sample to a contract laboratory for testing and link the contract lab ID to the sample ID. |
| 22, 189, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the assignment of an analyst to a sample. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the assignment of additional tests to a sample. |
| 63, 65, 101, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the cancellation of a test on a sample and enforce the entry of a reason. |
| 192, 209 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the cancellation of a test following the sample’s approval |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the un-cancellation of a test on a sample and enforce the entry of a reason. |
| 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the cancellation of a sample and enforce the entry of a reason. |
| 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the cancellation of a sample following the sample’s approval |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the un-cancellation of a sample and enforce the entry of a reason. |
| 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism for requesting the required number of sample bottles. |
| 31 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry and display of a sample note to document comments, data qualifiers or deviations from standard operating procedures, policies and/or practices, with the option to flag the note as reportable or non-reportable. |
| 50, 113, 114, 135, 186, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a list from which a sample comment may be selected, with the ability to override the predefined list. |
| 210, 211 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must send an alert when a sample issue is observed. |
| 134, 138, 144 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must send an alert when a sample is approaching its hold time. |
| 96 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must flag a sample when its hold time has been exceeded. |
| 58 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the disposal of a sample. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to automatically perform cross checks between a contract lab EDD/spreadsheet and verified agreements. |
| 139 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support chain of custody procedures. |
| The system must maintain the chain of custody of a sample. |
| 36, 71, 133, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the entry of chain of custody information during the steps of a sample life cycle. |
| 36, 71, 133, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the entry of chain of custody information for transfers to and from external testing laboratories. |
| 36, 71, 133, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support sample planning. |
| The system must provide a mechanism to create a sample planning schedule. |
| 152 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the entry of sample planning information in the schedule. |
| 152 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a summary of necessary supplies to be purchased in support of the sample planning schedule. |
| 127 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to export a sample planning schedule. |
| 152 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Test Processing Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must provide test life cycle management. |
| The system must support a test life cycle. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically capture the user ID, date and time for steps in a test life cycle. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prompt for an internal only lab comment for steps in a test life cycle. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically track the status of a test throughout its life cycle. |
| 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the status of a test to be displayed. |
| 192, 145, 166 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the documentation of exceptions. |
| 23, 189, 191, 193 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry of test results. |
| The system must support both manual and automatic entry of test results. |
| 59, 112, 157, 173, 192, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry of integer, decimal, and qualitative test results. |
| 59 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the creation and update of an analytical batch with the automatic insertion of predefined QC samples in addition to unknown samples. |
| 59, 91, 105, 106, 109, 198, 199, 201, 202, 205 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry of results by sample, by test, by analytical batch or by preparation date. |
| 30, 33, 55, 56, 59, 91, 105, 106, 173, 198, 199, 202, 205, 229 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the selection of a test result from a predefined list. |
| 59 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support test replicates and calculate relative percent difference between all permutations of replicates. |
| 116, 197, 199 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the automatic calculation of test results. |
| 59, 81, 110, 188 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the retrospective recalculation of test results. |
| 169 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the use of test specific automatic rounding rules for numeric results. |
| 59, 60 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the display of a test specific number of significant figures for numeric results. |
| 41, 59, 60 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the automatic comparison of a test result to predefined specifications and flag the result as in or out of specification. |
| 33, 54, 55, 56, 59, 91, 161, 191 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support internal and external testing. |
| 28, 29, 61, 157, 173 |
| □ □ □ □ |
| □ □ □ □ □ □ |
The system must support the entry and display of test information, including but not limited to:
· Laboratory Notebook Reference
· External Testing Facility
· SOP Reference
· Tested By (if not entered by the actual analyst)
· Test Date (Run Date) (if entered after the fact)
· Value Qualifier Code(s)
· Dilution Factor
· Workorder Number
· Comments (at any point of the workflow)
| 28, 29, 42, 44, 70 91, 110, 114, 131, 157, 192, 215, 229 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the browsing of a static data table and the display of descriptive information during the entry of test information. |
| 150 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry and display of a test or result note to document comments, data qualifiers or deviations from standard operating procedures, policies and/or practices, with the option to flag the note as reportable or non-reportable. |
| 50, 113, 114, 135, 185, 203 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a list from which a test or result comment may be selected, with the ability to override the predefined list. |
| 210, 211 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the entry of results by an uncertified analyst. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically send an email notification upon entry of a retest result and include both the original and retest results. |
| 158 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically send an email notification upon entry of test results for specific tests. |
| 160, 187 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically send an email notification upon failure of a test for specific tests. |
| 161, 191 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide information for tests that will not be completed. |
| 209 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the attachment of a file to a test. |
| 87 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry of test results via file upload or an API interaction. |
| The system must support the manual and automatic trigger of test result entry and release from an instrument. |
| 167, 168, 205 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the entry of results from an instrument that is unavailable due to an overdue calibration or maintenance activity. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the modification of test information. |
| The system must allow a result to be modified and enforce the entry of a comment without impacting the original Run Date. |
| 111, 137, 145, 217 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the modification of a test result following its review. without complete traceability and documentation. |
| 88 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the modification of test comments and codes in batch mode. |
| 223 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the review of a test. |
| The system must support the review of a test. |
| 65, 88, 89, 94, 149, 197 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must enforce peer review of a test. |
| 88, 89, 94 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the review of a test by sample, by test or by analytical batch. |
| 88, 89, 94, 147 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry of a sample, test or analytical batch comment at the time of test review. |
| 114 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the review of a test by an uncertified analyst. |
| 103 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the review of a test prior to the entry of all its results. |
| 220 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to contact the sample owner during review of a test. |
| 95 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the scheduling of a retest at the time of test review and by a customer after release. |
| 24, 62, 65, 116, 213 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to un-review a test and enforce the entry of a reason. |
| 212 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must flag the tests in an analytical batch when a QC sample issue is observed. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide the ability to re-release single or multiple test result. |
| 216 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Report Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must be capable of generating reports. |
| The system must provide an ad-hoc report writer. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow for the use of report templates |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide standard, out of the box reports. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must display the USGS logo in reports. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must be capable of including a barcode in a report. |
| 104 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the querying of information based upon predefined criteria including but not limited to lab code, medium code, sample submitter, project, work order code, date range, analyst, presence of a comment or data quality code. |
| 9, 27, 46, 69, 78, 79, 80, 83, 102, 104, 141, 142, 159, 182, 195, 196, 204, 218, 219 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the sorting of information based upon predefined criteria including but not limited to lab code, medium code, sample submitter, project, work order code, date range, analyst, presence of a comment or data quality code. |
| 9, 49, 80, 102, 104, 204, 218, 219 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the sorting of qualifiers by a predefined, static priority table. |
| 224 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must be capable of reporting in tabular format. |
| 83, 140 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must be capable of reporting in graphical format. |
| 34, 51, 52, 58, 69 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide trend analysis functionality for visualization of calibration and quality control performance over time and analysis number. |
| 34, 49, 51, 52, 58, 69 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide statistical information on test results including mean, standard deviation, relative standard deviation, range and confidence intervals. |
| 69 |
| □ □ □ □ |
| □ □ □ □ □ □ |
The system must provide custom reports, including but not limited to:
· Analytical Batch Report/Pour Protocol
· Analytical Service Request Report
· Backlog Report
· Budget Report (within and across units)
· Client Search Report
· Consumable Certificate of Analysis
· Consumable Inventory Report
· Contract Lab QA/QC Performance Report
· Control Chart
· Custom Pricing Request Report
· Exceptions Report
· Finance Report (Admin)
· Finance Report (Field)
· Financial and Production Forecasting Report
· Fiscal Year Log Summary
· Instrument Sequence Report
· Job Sheet (All)
· Job Sheet (Preparation)
· LCMS Vialing Report
· Master Income Report by Fiscal Year
· Master Income Report by Month
· Operational Report
· Preparation Batch Report
· Production Report
· QA/QC Report
· QC Trend Report
· Result Report
· Sample Bill
· Sample Tracking
· Submitted Sample Status Report
· Summary of Analytical Work
· Test Status Report
· Turnaround Time Report
· Variance Report
· Verification Backlog by Section
· Worklist Report
· Preparation Run Due Date Report 7, 8, 18, 20, 26, 34, 37, 38 47, 49, 51, 58, 69, 72, 73, 79, 80, 82, 92, 98, 102, 104, 107, 108, 115, 117, 124, 132, 136 140, 141, 142, 146, 159, 164, 182, 193, 195, 196, 204, 206, 219
| The system must support different report generation mechanisms |
| The system must support the manual generation of a report. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the entry of a comment at the time of manual report generation. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must enforce the entry of an electronic signature at the time of manual report generation for critical reports. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the automatic generation of a report based upon a predefined trigger. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support different report delivery modes. |
| The system must support the on-screen display of a report. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the hardcopy printout of a report. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the electronic transmission of a report file directly from the LIMS system to a local system or via email. |
| 132, 193 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the export of a report in a format compatible with Portable Document Format(.pdf), plaintext (.txt, Unicode), comma separated value (.csv, IETF RFC-4180), Microsoft Word (.docx) and Microsoft Excel (.xlsx). |
| 19, 83, 104, 121, 142, 151, 196 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the upload of a sample bill in a predefined format to the Bureau Business Management (financial accounting) System. |
| 16 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Label Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must provide custom labels. |
| The system must provide custom labels including but not limited to: |
· Sample Labels
· Instrument Labels
· Consumable Labels
| 92, 174, 189, 227 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support label information in human readable, 2D barcode, QR code, and radiofrequency identification format. |
| 174, 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the creation of labels of different sizes and shapes including but not limited to the American Barcode 0.5” x 1” roll labels |
| 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support label printing |
| The system must support automatic label generation of a default quantity on a predefined label printer. |
| 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support manual label generation with a prompt for quantity and label printer. |
| 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must be compatible with commercial printers including but not limited to Zebra 110xi4 commercial label printers and laser printers |
| 189 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Storage Location Management Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support the management of storage locations. |
| The system must support the use of single level storage locations. |
| 90 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the use of multi-level storage locations. |
| 90 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must maintain an inventory for each storage location. |
| 90 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Consumable Management Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support the creation of consumables. |
| The system must provide a list of USGS vendors for the purchase of a consumable. |
| 179 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the creation of a purchased or prepared consumable. |
| 85, 109, 177, 207 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically generate a unique consumable ID of a predefined format. |
| 85, 109, 177 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry of consumable information. |
| 85, 109, 177 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the access of the spike lot database during the creation of a spike consumable. |
| 207, 208 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the attachment of files to a consumable. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support a consumable life cycle. |
| The system must support a consumable life cycle. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically track the status of a consumable throughout its life cycle. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the status of a consumable to be displayed. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically expire a consumable. |
| 85 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically flag a consumable as unavailable when it expires or is due for retest. Must allow for status update from expired to reverified/good |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must manage the inventory of a consumable. |
| The system must allow the entry of an initial consumable amount and maintain its inventory after each use. |
| 85, 177 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically flag a consumable as unavailable when its inventory is below a predefined critical level. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow for the tracking and usage of a consumable and associated a cost with its usage. |
| 49 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the export of spike consumable data. |
| The system must support the reporting and export of spike consumable data for use by clients in the field. |
| 207, 208 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Instrument Management Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support the creation of an instrument. |
| The system must support the creation of an instrument. |
| 84, 226 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically generate a unique instrument ID of a predefined format. |
| 226 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the entry of instrument information. |
| 84 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the attachment of file to an instrument. |
| 93, 108 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support an instrument life cycle. |
| The system must support an instrument life cycle. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically track the status of an instrument throughout its life cycle. |
| 226 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the status of an instrument to be displayed. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically update the status of an instrument. |
| 97, 226 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow a manual update of the status of an instrument. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must manage the calibration of an instrument. |
| The system must support the definition of an instrument calibration schedule. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must send an alert when an instrument is due for recalibration. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically flag an instrument as unavailable when it is due for calibration. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the entry of calibration information. |
| 205 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow an unscheduled calibration. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must manage the maintenance of an instrument. |
| The system must support the definition of an instrument maintenance schedule. |
| 49 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must send an alert when an instrument is due for maintenance. |
| 49 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically flag an instrument as unavailable when it is due for maintenance. |
| 49 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the entry of maintenance information. |
| 49 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow an unscheduled maintenance. |
| 49 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must manage the usage of an instrument. |
| The system must provide a mechanism to reserve an instrument for use. |
| 97 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must track the usage of an instrument and associated a cost with its usage. |
| 49 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Analyst Certification Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support an analyst certification life cycle. |
| The system must support an analyst certification life cycle. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically track the status of an analyst certification throughout its life cycle. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the status of an analyst certification to be displayed. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically update the status of an analyst certification. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow a manual update of the status of an analyst certification. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must manage the certification of an analyst. |
| The system must support the definition of a certification schedule for each analyst/test combination. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must send an alert when an analyst is due for recertification for a test. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically flag an analyst as unavailable to perform a test when it is due for recertification for that test. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow the entry of certification information. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow an unscheduled certification. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the entry of results by an analyst that is not certified for that test. |
| 75 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Customer Billing Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
The system must support the creation of an Analytical Service Request bill.
| The system must support the creation of an estimated Analytical Service Request bill. |
| 12, 17 154 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the creation of a final Analytical Service Request bill. |
| 12, 16 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must initiate billing during login of the Analytical Service Request |
| 14 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must have access to a pricing catalog during the creation of an Analytical Service Request bill. |
| 13, 154 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must have access to instrument and consumable usage costs during the creation of an Analytical Service Request bill. |
| 49, 177 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must ensure that an Analytical Service Request bill meets the customer proposal terms. |
| 12, 154 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support pre-billed, billable and pre-paid samples. |
| 99 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support external and external billing. |
| 12, 154 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the inclusion of return shipping costs. |
| 178 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide the ability to add a rush surcharge to analyte, without having to create a rush analyte. |
| 222 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow users to define a custom proposal to define pricing. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow for management to confirm a custom proposal. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the management of an Analytical Service Request bill. |
| The system must support the ability to adjust an Analytical Service Request bill automatically. |
| 11, 15 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow post-login adjustments based on sample destruction, test addition and test deletion. |
| 15 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must track the status of an Analytical Service Request bill. |
| 10 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow access to an Analytical Service Request bill via a billing portal. |
| 8 |
| The system must allow a monthly upload of an Analytical Service Request bill to the Department of Interior Financial Business Management System. |
| 16 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the tracking of payments and account budgets |
| The system must allow multiple payment options including but not limited to international and domestic credit cards. |
| 126 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must accept and track prepayment amounts. |
| 10 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must track a budget’s pending and applied charges. |
| 10, 14, 16 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must allow one billing account to pay for multiple sample analyses. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
Client Portal Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must provide a client portal. |
| The portal must allow a prospective user to request access to the portal. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The portal must allow a client to create a quote by selecting analyses to be performed. |
| 86 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The portal must allow the client to submit an Analytical Service Request. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The portal must allow the entry of sample information. |
| 86 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The portal must allow test results and historical data to be viewed. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The portal must provide alerts to clients at various stages of production, receipt, and billing. |
| 187 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The portal must provide a mechanism to communicate with USGS personnel. |
| 156 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the reporting and export of financial data. |
| 8, 9, 228, 230 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Interface Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must provide interfaces for the import of test results from laboratory instruments. |
| The system must support the import of test results from the following laboratory instruments: |
· Alpkem Rapid Flow Analyzers
· Agilent 5977B GC/MS
· Agilent 5977A GC/MS
· Agilent 5977C GC/MS
· Agilent 5973 GC-MS
· Agilent 5975 GC-MS
· Agilent 7890B GC TCD/FID System
· Agilent QT 7010B GC-MS/MS
· Agilent 8453 UV/VIS
· Agilent 6460 Triple Quadrupole LC/MS
· Agilent 6495 Triple Quadrupole LC/MS
· Agilent 8900 Triple Quadrupole ICP-MS
· Agilent 7900 ICP-MS
· Beckman LS 600LL Scintillation Counter
· Dionix 1500 Ion Chromatographs
· Exeter CE-440 Elemental Analyzer (EA)
· Hach 2100an Turbidimeter
· Los Gatos Research TIWA-45-EP
· Los Gatos Research DLT-100
· Metler Toledo Digital Scales
· Metrohm pH meter
· Metrohm Ion Chromatographs
· Ohaus Digital Scales
· Perkin Elmer Nexion 350D ICP-MS
· Perkin Elmer Optima 8300 ICP-OES
· Perkin Elmer Optima 4300DV
· Perkin Elmer Tricarbon Liquid Scintillation Counter
· Perkin Elmer Quantulus GCT Liquid Scintillation Counter
· Sartorius Digital Scales and Microbalances
· Seal QuAATro 39 with autosamplers
· Shimadex TOC-L Carbon Analyzer
· Shimadzu GC-8 GC-ECD with Peaksimple
· Shimadzu GC-2010 GC-ECD with Peaksimple
· Shimadzu GC-8 with EZchrome
· Thermo ASE 350
· Thermo Scientific DELTAplusXP
· Thermo Scientific DELTA V PLUS
· Tekran 2600 CVAS
· Teledyne Quictrace M-800
· Thermo Dionix Intergrion
· Thermo Kone AquaKem 600 DA
· TIM870 Radiometer
| 93, 167, 168, 172 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the definition of parsing routines to import test results of different formats. |
| 93, 167, 168 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the import of test results from an instrument that is flagged as unavailable. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support different instrument interface modes. |
| The system must support the manual and automatic import of test results. |
| 93 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the import of test results via a direct connection. |
| 93 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the import of test results via a file intermediate. |
| 93 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support a unidirectional import of test results. |
| 93 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support a bidirectional download of worklists and import of test results. |
| 93, 108 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to track the import of test results. |
| 43 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to handle test result import problems. |
| The system must detect and process errors that are encountered during the import of test results. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a contingency plan for a failed import. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must be capable of interfacing with outside system. |
| The system must support the interface with the following outside systems: |
· Batch Data Loader (AQUARIUS Samples)
· DataHub
· FBMS Financial Reporting System
· Field Spike Calculator
· Lab Data Capture Unit (Mass Hunter)
· Laboratory Analytical Services Division Web Presence
· Monitoring Location Registry
· OneStop
· Pay.Gov
· Quality Systems Branch Applications
· Reference List Management System
· Unified Field Application Refer to Reference 3: ‘Application Interface Details’.
| 16, 126, 127 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must identify sample results that have been reloaded. |
| 225 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism for migrating data. |
| The system must provide a mechanism for migrating data from the following legacy systems: |
· LIMS for Lasers Access Database
· LIMS for Stable Isotopes Access Database
· StarLIMS v9
· StarLIMS v11 Refer to Reference 4: ‘Current Data Volume Details’.
Electronic Signature Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support the use of electronic signatures. |
| The system must enforce the entry of an electronic signature at predefined processing steps, at the time the step is performed. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The electronic signature must consist of a user id, password and reason for signing. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the use of a predefined selection list of reasons for signing, tailored for the function that is being performed. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must preserve the integrity of an electronic signature. |
| The system must prohibit the modification of an electronic signature at the time of signing. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the deletion of an electronic signature at the time of signing. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide traceability for an electronic signature. |
| The system must link an electronic signature to a record that contains the user id, date and time of signing and meaning of the electronic signature. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The electronic signature must be traced back to the individual that entered it. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must enforce that an electronic signature is unique to one individual. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
Electronic Record and Audit Trail Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support the use of electronic records. |
| The electronic record must be viewable in electronic and human readable form. |
| 60, 192, 200 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The electronic record must be accurately and completely displayed in paper form. |
| 60, 192, 194 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must retain and be able to retrieve an electronic record throughout the electronic record retention period as specified by government policy. |
| 60, 192 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must maintain an audit trail. |
| The system must maintain an audit trail for the creation, update and deletion of an electronic record. |
| 32, 45, 111, 200 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The audit trail must contain the user id, date and time, action performed, IP address, original value, new value and reason if appropriate. |
| 32, 45, 111 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The audit trail must not obscure previously recorded information. |
| 32, 45 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The audit trail must be viewable in electronic and human readable form. |
| 32, 45 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The audit trail must be accurately and completely displayed in paper form. |
| 32, 45 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must retain and be able to retrieve an audit trail record throughout the electronic record retention period as specified by government policy. |
| 70 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must preserve the integrity of the audit trail |
| The system must prohibit the manual entry of information into the audit trail. |
| 70 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the modification of information in the audit trail. |
| 70 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the deletion of information from the audit trail. |
| 70 |
| □ □ □ □ |
| □ □ □ □ □ □ |
Security Requirements
| User |
| Implementation Strategy |
| Custom Complexity |
| Requirement |
| Detailed Description |
| Story |
| Base Cfg. Base Custom None |
| 1 2 3 4 5 n/a |
| The system must support the management of LIMS and client portal user accounts. |
| The system must support the creation of a user account. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must enforce the unique identification of a user account. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit the reuse of the unique identification of a user account. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
The system must support a role based assignment of functional privileges to a user account. Roles include but are not limited to:
· Analyst
· Business Analyst
· Contract Lab COR
· Data Clerk
· Field
· Lab Manager
· Login
· QA
· QA Manager
· System Administrator
| 21, 103, 166 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the manual disabling of a user account. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the manual enabling of a user account. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support the management of passwords. |
| The system must enforce that a password meets or exceeds predefined format and length criteria. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to change a password. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically expire a password after a predefined time interval. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must provide a mechanism to reset an expired password. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must control access to and within the system. |
| The system must support HSPD-12 PIV credentials and/or USGS Active Directory based user authentication. |
| 232 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must restrict access to authorized users and enforce the entry of a valid user id and password. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must not display a password in human readable form. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit a user with a disabled user account from accessing the system. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must prohibit a user with an expired password from accessing the system. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must record unsuccessful login attempts. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must automatically disable a user account after a predefined number of unsuccessful login attempts. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must restrict function access to those that are assigned to a user account. |
| 21, 103, 166 |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must support an automatic timeout. |
| The system must automatically log a user account out after a predefined period of inactivity. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
| The system must enforce entry of a valid user id and password to regain access following an automatic timeout. |
| n/a |
| □ □ □ □ |
| □ □ □ □ □ □ |
Infrastructure, Implementation and Support Requirements
| Requirement |
| Detailed Description |
| Story |
| Yes No n/a |
| The vendor must provide information on supported infrastructure solutions. |
| Is an on-site infrastructure solution supported? |
If yes, the vendor will provide information on the following components for an on-site infrastructure solution, including the version required for proper execution and support of their product:
· Established database platforms
· Minimum requirements for clients and servers
· Web client interface
· Browsers The system’s on-site infrastructure components, if any, must reside in a central location.
Is a cloud hosted infrastructure solution supported?
If yes, the vendor will provide information on a cloud hosted infrastructure solution.
Is a vendor managed infrastructure solution supported?
If yes, the vendor will provide information on a vendor managed infrastructure solution.
Is a third-party infrastructure solution supported?
If yes, the vendor will provide information on a third-party managed infrastructure solution.
| The vendor will provide advantages and disadvantages of each supported infrastructure solution with a concrete recommendation on how to proceed. |
| n/a |
| □ □ □ |
| The system must support unique operating environments. |
| Does the system support the following unique operating environments? |
· Development
· Validation
· Production
| The system must meet USGS operating criteria. |
| The vendor will provide a list of supported non-proprietary database platforms. |
| 183 |
| □ □ □ |
| Is the system accessible as a web client using a USGS supported browser (currently Microsoft Edge)? |
| 53 |
| □ □ □ |
| Does the system support the use of a TCP/IP application programming interface? |
| 172 |
| □ □ □ |
| Does the system support the use of open-source language(s) for development? |
| 35 |
| □ □ □ |
| Does the system support the use of GIT software for tracking files during software development? |
| 231 |
| □ □ □ |
| If the system is Software as a Service, is it FedRamp compliant? |
| 232 |
| □ □ □ |
| Is the system Section 508 compliant? |
| n/a |
| □ □ □ |
| Does the system support Zero Trust principles? |
| 232 |
| □ □ □ |
| The system’s infrastructure must be secure and supported. |
| The vendor will provide information on how a secure environment is maintained for cloud hosted, vendor managed and third-party managed infrastructures. |
| 232 |
| □ □ □ |
| The vendor will provide information on how a controlled environment that meets vendor specifications is maintained for cloud hosted, vendor managed and third-party managed infrastructures. |
| n/a |
| □ □ □ |
This is the start of the file's text. The full file is on GovTribe.