NMLETS Replacement Project Traceability Matrix - … · Computer Projects of Illinois, Inc. NMLETS...

Computer Projects of Illinois, Inc. NMLETS Replacement Project Traceability Matrix

This document is considered confidential and is intended for use, possession and dissemination only by those parties to whom it was distributed by Computer Projects of Illinois, Inc.

NMLETS Replacement Project Traceability Matrix

Version 2.4

Provided to

NM DPS

Provided by



Revision History Date Version Description Author

03/29/2010 1.0 RFP Requirement Trace Lorne Sawatzky 05/21/2010 2.0 RFP Requirement Trace Lorne Sawatzky

04/11/2011 2.1 Corrections based upon actual implementation Lorne Sawatzky

05/03/2011 2.2 Corrections based upon implementation specifics Lorne Sawatzky

05/11/2011 2.3 Updated after testing Lorne Sawatzky 05/12/2011 2.4 Updated after final testing Lorne Sawatzky



Table of Contents

1. Introduction 4 1.1 Purpose 4

1.2 Scope 5

1.3 References 5

1.4 Overview 6

1.5 Definitions, Acronyms, and Abbreviations 6

2. Requirements Traceability Matrix 9 2.1 Traceability Matrix Structure 9

2.2 Description of Matrix Fields 9

2.3 OpenFox™ Module Descriptions 10

2.4 Requirements Traceability Matrix 13

2.5 Signature Block 51



1. Introduction

The Traceability Matrix is a document provided to insure that each of the requirements as specified by the NM DPS Request for Proposal is covered by this project. This document has interest for the implementers as well as all of the stakeholders of the project. The purpose of the NMLETS Replacement Project is to help provide safety to the citizens of New Mexico by providing a new system to the New Mexico law enforcement agencies based upon the latest technologies and standards. The new system will utilize web services and XML wherever possible to modernize the system operation.

1.1 Purpose

The requirements traceability matrix is a table used to trace project life cycle activities and work products to the project requirements. The matrix establishes a thread that traces; requirement identification, design specification, implementation and testing.

The purpose of the Traceability Matrix is to allow the project managers from both the vendor (CPI) and the client or user (NM DPS) to trace a requirement from the source of the requirement such as; the Request for Proposal, or the CPI Response to the Request for Proposal, to the actual implementation. The project managers will be able to easily reference a requirement, how it was implemented and how it must be tested.

The proposed solution for this project is based upon customization of standard products. The rules for the implementation of the system are contained in the Project / System Design Specification. This document ties the project documentation together by referencing, where necessary the other documents. This document is of interest to groups such as the following:

• NM DPS Project Manager

• CPI Project Manager

• NM DPS Stakeholders

• NM DPS Technical Staff

• NM DPS Training Staff

• CPI Technical Staff

This document is expected to be used to insure that the requirements as laid out by the NM DPS are addressed in the Project Design Specification and implemented in an agreed upon



manner.

1.2 Scope

This document applies to the Functional and Technical Requirements as published in the NMLETS Replacement Project Request for Proposal 90-790-000827. As stated earlier this document may also be used for the creation for the project test plan.

1.3 References

The following documents are referenced throughout the Traceability Matrix.

Document Title / Description Date/ Version Publisher

Request for Proposal RFP# 90-790-000827 NM DPS NMLETS RFP Pre-Bid Vendor Questions and Answers Addendum 1 12/02/2008 NM DPS

NMLETS RFP Pre-Bid Questions and Answers Addendum 2 12/26/2008 NM DPS NMLETS Replacement Project Response to Proposal RFP # 90-790-000827 01/12/2009 CPI

NM DPS Contract 09/28/2009 NM DPS / CPI

OpenFox™ System Guide Version 2.4 CPI OpenFox™ Unix Operations Guide Version 1.1 CPI OpenFox™ Desktop Guide Version 2.01 CPI OpenFox™ Messenger Guide Version 2.01 CPI OpenFox™ Form Configurator Guide Version 1.3 CPI OpenFox™ Interceptor Terminal Guide Version 1.3 CPI OpenFox™ Archive & Retrieval Description CPI Specification for FoxTalk TCP/IP Protocol TBD CPI Project Report 1 11/05/2009 CPI Project Report 2 12/18/2009 CPI Project Report 3 12/22/2009 CPI Project Report 4 01/04/2010 CPI Project Report 5 01/27/2010 CPI Project Report 6 03/03/2010 CPI Project Report 7 03/03/2010 CPI Project Report 8 05/12/2010 CPI Project Report 9 05/21/2010 CPI Project Report 10 06/11/2010 CPI Project Report 11 06/30/2010 CPI Project Report 12 07/16/2010 CPI Project Report 13 08/03/2010 CPI



Document Title / Description Date/ Version Publisher

Project Report 14 08/17/2010 CPI Project Report 15 09/03/2010 CPI Project Report 16 10/06/2010 CPI Project Report 17 10/31/2010 CPI Project Report 18 11/31/2010 CPI Project Report 19 12/30/2010 CPI Project Report 20 01/31/2011 CPI Project Report 21 02/07/2011 CPI Project Report 22 03/15/2011 CPI

1.4 Overview

The Traceability Matrix contains a diagram indicating the use of the document, a description of each of the fields in the table, the name and description of the OpenFox™ Modules and the Traceability Matrix Table itself.

1.5 Definitions, Acronyms, and Abbreviations

A&R OpenFox™ Archive and Retrieval product AIX IBM's Unix Implemenation API Application Program Interface

Bingo Cards A crude method of providing advanced authentication – this technology is patented and is quite expensive to implement

CAD Computer Aided Dispatch (or computer assisted dispatch)

CANDLE Collaboration between AAMVA and Nlets for Drivers License Exchange

CCH Computerized Criminal Histories CHIEF Criminal History Information Exchange Format CHRI Criminal History Record Information CJIS Criminal Justice Information System CJIS Div. FBI Criminal Justice Information Services Division

Configurator An interactive tool allowing system administrators to add, change or delete elements in the system

CPI Computer Projects of Illinois, Incorporated Csv Comma separated values file format

http://www.fbi.gov/hq/cjisd/cjis.htm�



Desktop The OpenFox™ Desktop product which provides the platform for several OpenFox™ Client Software Applications

DOC Department of Corrections EMC The EMC corporation (disk storage units and other enterprises) FBI Federal Bureau of Investigation FBI CJIS FBI Criminal Justice Information Services Division FIPS 140-2 Federal Information Processing Standard – computer security standard

Forms Configurator The OpenFox™ Forms Configurator which allows administrators or developers to add, modify or change Messenger forms interactively

FoxTalk The application-to-application TCP protocol for communicating between the Switch and Desktop

GJXDM Global Justice XML Data Model GLOBAL Global Justice Information Sharing Initiative GUI A graphical user interface HTML Hypertext Markup Language ICE Immigration and Customs Enforcement IEPD Information Exchange Package Documentation

IJIS Institute Founded on the principal that public/private partnerships in the area of justice system information sharing would contribute to the successful implementation of integrated justice systems throughout the country.

INS Immigration and Naturalization Service INTERPOL International Criminal Police Organization IP Internet Protocol

JAR Java Archive file is a file that contains the class, image, and sound files for a Java application or applet gathered into a single file.

JAVA A programming language developed by Sun Microsystems which allows World Wide Web pages to contain code that is executed on the browser.

LAN Local-area Network

MKE Configurator Message key configurator allows the administrator to add, change or delete message transactions

Messenger The OpenFox™ Messenger law enforcement browser initiated client software package

NCHIP National Criminal History Improvement Program NCIC Nation Criminal Information Center NIC NCIC Identification number

nexTEST Product name for NCIC certification Testing software from Peak Performance Solutions

NIEM National Information Exchange Model

http://www.fbi.gov/�

http://www.fbi.gov/hq/cjisd/cjis.htm�

http://www.ijis.org/�



http://searchdatamanagement.techtarget.com/definition/0,,sid26_gci211790,00.html�

http://searchwebservices.techtarget.com/sDefinition/0,,sid9_gci212415,00.html�

http://searchwebservices.techtarget.com/sDefinition/0,,sid_gci211580,00.html�

http://www.peakps.com/�

http://www.peakps.com/�



NIJ National Institute of Justice NISP Nlets Interstate Sharing of Photos Nlets National Law Enforcement Telecommunications System NMDPS New Mexico Department of Public Safety NMLETS The messages processing system being replaced ORI Originating agency identifier PDF Portable Document File Format RCP Reset Computer Program RFP Request for Proposal RMDTS Remote Data Terminal System RSA The Security Division of EMC SAM Site Automated Monitoring SAN Storage area network (disk storage) Soundex A method of coding a name for general searching SOR Sex Offender Registry SRFERS State, Regional, Federal Enterprise Retrieval System TCP Transmission control procedure

Third Party A party other than NMDPS or CPI whose products and or services may be required in the implementation

.txt Text file format Unix A type of computer operating system User Configurator A GUI tool to allow administrators to add, change or delete users US DOJ United State Department of Justice US NCB United States National Central Bureau VINE Victim Information and Notification Everyday VNS Victim Notification System

Web Browser An application for retrieving, presenting and traversing information on the World Wide Web

Web Services A well known method of communications between systems based upon TCP/IP

Windows 2000 A computer operating system Xls Microsoft excel spreadsheet file format XML eXtensible Markup Language XSTF Global Justice XML Structure Task Force

http://www.ojp.usdoj.gov/nij/�

http://www.nlets.org/�

http://www.usdoj.gov/�

http://www.usdoj.gov/usncb/�

http://www.appriss.com/VINE.html�

http://www.w3.org/XML/�

http://justicexml.gtri.gatech.edu/�



2. Requirements Traceability Matrix

2.1 Traceability Matrix Structure

The Traceability Matrix starts with an identification of the requirements, proceeds to creation of the design specification which is used to code the customizations. As stated earlier a test plan can be created by referring to this document. Each test is linked back to the specific requirement.

2.2 Description of Matrix Fields

The following provides the name of the fields that are included in the Requirements Traceability Matrix Table with an explanation of the fields:

REQ ID – This column is the requirement id from the RFP Response. If a requirement originates from another source it will be marked as OTH (Other) and the remarks field will have further details.

Requirement Statement – This column contains the requirements statement as included in the RFP Response or as created during the discovery and design phase.

Doc Source – This column provides a section in the Project Design Specification where the requirement and the implementation method are detailed. The Design Specification is abbreviated as DS with the appropriate section number. If the requirement is discussed in a document other than the DS it will call out the source such as Project Report which is abbreviated to PR, SG for Systems Guide, DG for Desktop Guide, MG for Messenger Guide, AR for Archive & Retrieval Description, etc.

IMP (Implementation Method) – This column indicates whether the requirement is implemented with standard (S), customized (C), hardware (H), other (O).



Program Module – This column is the program name of the process within the OpenFox™ Suite of Products which will provide the required functionality. A list of program names and the purpose of the module follows this section.

Test Comp – This column contains a status with values as follows:

• P – pass indicates that the requirement has been tested and passed

• F – fail indicates the test has failed

• CP – conditional pass indicates that a condition as specified in the Remarks/Notes column will change the status to pass

• D – deleted indicates that the requirement has been deleted after the beginning of the project by mutual CPI and NM DPS agreement

Remarks / Notes / Test Method – This column will contain a description of the requirements as well as a brief description of the method of providing evidence that the requirement has been met. The Test Plan will provide further detail on the method of testing.

2.3 OpenFox™ Module Descriptions

The purpose of the following table is to provide a very brief description of the modules within the OpenFox™ Message Switching System that are common to all installations as well as those modules which are required for customization of the system to meet project requirements.

Name Purpose Description Iplfox Initial Process OpenFox™ startup/stop and management process.

Additionally handles the Station Counter update at midnight.

Cfs Configuration Service Interface to GUI OpenFox™ Configurator. Handles all OpenFox configurations.

CP Command Processor Handles message switch administrative commands. Generally commands that begin with /S??? and /R??? are handled in this program.

D1 Command Interface Operator command line interface for operating the system

ED End-of-Day Performs end of day queue scan and updating of MKE statistics

FM Forms Management Forms manager for the OpenFox Desktop/Messenger environment

Fxtalk Fox Talk communication

This process provides the communications support for all devices utilizing Fox Talk including Desktop.



Name Purpose Description HP Help Processor Provides HELP for the various commands in the system. The

command /HELP is handled by this program. From a command line interface, type /help help to get information about this HELP command.

INTSRV Intercept Interface Intercept function to handle problem or non-routable messages

IP Interface Input Processer

Handles input messages from stations and agency interfaces, stores the messages on disk and queues the messages to the Transaction Processor

JJ Journal Process Creates a copy of the message transaction to feed the Archive system. The /LOGJ command is handled by this program.

JQ Journal Search Retrieves and re-sends messages from disk. The /FIND command is handled in this program. NOTE: If the modifier “/TA???” is in this FIND command, this program will pass the command to the JT program.

JT Journal Tape Retrieves archived tape messages. See description of the JQ program.

JW Journal Write Journals messages for output to tape. The command /LOG is handled by this program. The output of this program is used as input for the JT program.

LICSRV License Server License Server for OpenFox Desktop

NCITCP NCIC Interface TCP/IP Interface to NCIC

NLTTCP NLETS Interface TCP/IP Interface to NLETS

OP Output Processer Handles message delivery and De-Q between the interface programs and the system

OPAID Operator Aid Interface to GUI client to handle admin functions

OR Organizer Process Handles purging of messages with the added possibility of re-queuing the purged messages. The /PURGE command is handled in this program.

PS Print Service Process to print all OpenFox™ ‘system’ messages

RC Reports Computer and Timer Command

Creates reports for the /DT?? And /DC?? Commands.

RK Reports Keys Processes commands relating to MKE/MFC’s. The command /DK?? Is handled by this program.

RL Reports List Creates the list mail reports. The command /LIST/??? Is handled by this program.

RP Reports Port Creates port reports. The command /DP?? Is handled by this program.

RS Reports Station Processes commands relating to stations

RU Reports User, Agency and License

Processes commands relating to users, agencies and licenses. The commands: /DU??, /DA?? and /DL?? Are handled by this program.



Name Purpose Description SM System Maintenance Performs system maintenance tasks. It is a tool for CPI

system engineers that is invoked for analysis of various system issues

TCPMAN TCP Manager Manages TCP communications tasks

TI Timer process Links to TISPCL (Special per client) to manage functions such as re-trying stations when communications fails

TP Transaction Process Verifies, edits and processes all incoming messages and queues resulting output messages

TR Trace Reports Creates Trace Reports. The command /TRACE is handled by this program.

UR User Repository Interface

Controls transfer of update data from external User Repository to OpenFox™

US User Service Validates OpenFox™ user logon

Configurator Provides configuration capability

The current configurator provides the ability to add configuration elements such as message keys, stations (devices), group codes, ORI’s, NCIC codes, Watchdog entries, etc.

New Configurator

Provides user id configuration capability

The new configurator will gradually replace the current configurator. It currently provides the ability to configure user id and roles.

Desktop Provides environment for client applications

The Desktop module provides the environment for client software applications such as Messenger, Form Configurator, and Archive Client

Messenger Provide robust workstation capability

The Messenger module is the client application which provides the law enforcement workstation software to be deployed statewide.

Form Configurator

Messenger Forms The Form Configurator provides the ability to configure forms and other XML resource files to be used by the Desktop / Messenger applications.

Archive Client

User Interface to the Archive & Retrieval system

The Archive & Retrieval client software is a module in the Desktop environment and allows users to access, retrieve and display logged message transactions.

HA High Availability for OpenFox™

This capability is composed of two separate components; the High Availability software that executes on the servers and the client software which displays the status of the operating environment and allows manipulation by administrators.



2.4 Requirements Traceability Matrix

The requirement number has come directly from the RFP and is the source of most of the requirements. The requirement itself is detailed in the RFP and RFP response. In some cases the requirement has been modified during the discovery phase or while explaining the standard features in the system. Other documentation such as the design reports details additional requirements that were discovered during the creation of the design specification document. These requirements are included at the end of this section.

Functional Requirements REQ

ID Requirement Statement Doc

Source IMP Program

/ Module Test

Comp Remarks/Notes/Test Method

BP-1

The proposed solution must accommodate changes to existing message keys by NM DPS administrators and the addition of new message keys as required.

SG S MKE Configurator

P

This functionality is provided through the use of the OpenFox™ MKE Configurator. CPI will use this module to provide all MKE definitions. NM DPS staff will be trained on its use and may utilize the tool to make changes in the future.

BP-2 The proposed solution should minimally provide all of the functionality of the current NMLETS environment

DS (Entire) C All P

The Design Specification document has been provided to document how the new system will accomplish this task. This requirement will be proven by observing the operation and reviewing the results to determine if any functionality is missing. The system was placed into operation on February 1st, 2011. Functionality was found to be missing as stated in PR 22.

BP-3 The proposed solution should minimally provide the interface and protocol capabilities of the current NMLETS environment.

DS (9) C Interfaces P

Section 9 of the Design Specification contains the description of the various protocols as agreed upon. It should be noted that some of the existing protocols have been swapped and additional ones have been added. This requirement will be proven by observing the behavior of the system during normal operations. Any problems arising will be documented and will be fixed.



REQ ID

Requirement Statement Doc Source

IMP Program / Module

Test Comp

Remarks/Notes/Test Method

BP-4 The proposed solution should minimally provide the operational capacity of the current NMLETS environment, including photos.

DS (9.1, 9.2, 9.3, 9.6, 9.7)

C All P

The system will be tested in production to determine if the operational capacity of the old system is matched in the new system operating under the constraints of the new system characteristics including XML and photos.

BP-5 The proposed solution should provide transaction-level/group user authorization capabilities.

DS (7.4.4, 7.4.5)

S New Configurator TP

P

This requirement is documented in the design specification and is provided by the user and profile configuration capabilities. This requirement will be tested by logging on as a user whose profile does not contain and MKE and attempting the transaction. Then logging on as a user whose profile contains the MKE and attempting the transaction again.

BP-6

The proposed solution should accommodate changes to production applications without impact to operations, and the vendor should explain how this is accomplished.

SG (4.1.1.2)

S Iplfox, CP P

This capability is standard and for actual software is achieved by executing the /RCP (program name). This requirement will be tested by changing a module and executing the command and observing the results. In addition, any configuration service can be used to effect how the system operates.

BP-7 The proposed solution should provide a means for real-time end-user notifications regarding system availability.

DG (3.1) S Desktop P This requirement is implemented in Messenger and can be tested by disconnecting the session and observing the connection status indicator.

BP-8

The proposed solution should provide an originating agency identifier (ORI) table that includes not only agency name, but also mailing address, physical address, telephone number, alternate telephone number, fax number, secondary fax number, terminal agency coordinator, terminal or device ID, etc. This information must be available so that various pieces of information can be extracted and used, depending on the purpose.

SG (3.9) S Agency Config

P

Originally CPI had planned to create an ORI table to meet this requirement. However it was decided that this capability can be met with the New Agency Configurator. This requirement can be tested by executing the Agency Configuration and reporting.



REQ ID



Test Comp


BP-9

The proposed solution should be capable of processing batch transactions from local agencies (e.g., processing a group of inquiries on a batch of data items or processing groups of record entries or modifications).

Messenger Guide

C Messenger P This capability will be provided in Messenger and can be tested by creating a batch file and observing the results.

BP-10

The proposed solution should provide a description of the system’s ability to meet the online storage requirements. Note any impacts on system performance and recommendations for an alternate approach to having access to detailed transactions for retrieval and analysis.

DS 6.7 H NA P The capacity of the SAN is described in section 6.7 of the Design Specification.

BP-11 The proposed solution should include use of and descriptions of the standard techniques utilized that enable scalability, security, and integrity.

DS (6, 7.4)

S All P

Scalability is provided in the hardware configuration. Security measures are described in section 7.4 of the DS and is implemented with valid user id, password, IP address, as well as hardware fingerprint. Security will be tested by monitoring the operation of a connection from start to finish.

BP-12

The proposed solution should handle errors (both user and application) in a consistent manner with the display of a message that indicates the problem.

MG (4.5.6, 5.2.3)

S Messenger P The Messenger client software has a standard technique for handling errors. This requirement will be tested by making errors on data entry and the operation observed.

BP-13 The proposed solution should provide editing capabilities for correction of errors in data.

MG (4.5.6, 5.2.3)

S Messenger P The Messenger product allows the operator to correct errors. This requirement can be tested by filling in an error in a form and observing the action of the Messenger software.

BP-14

The proposed solution should utilize application server technology that allows tasks to be off-loaded onto other computers or processors to prevent a loss in performance as system usage grows.

DS 9 C HFS, RIF, CHSQ, CHSU

P

The production platform is composed of system A which normally runs the message switch, system B which normally runs the database applications, system C which acts as a standby for the operations of either system A and system B. This capability can be shown by observation of the operations.



REQ ID



Test Comp


BP-15 The proposed solution should allow users to receive priority messages first, regardless of what other information is queued.

SG (3.4) S Configurator P

The Configurator allows the assignment of priorities. This requirement will be tested by sending messages with varying priorities to an offline device and then received. The order of reception will be observed and verified.

BP-16

The proposed solution should utilize compression techniques for data, message, and image packets to maximize system performance, including an explanation of the compression method used.

NA S FoxTalk Messenger

P

This requirement will partially be provided by Java Web Start, the JarDiff capability and gzip compression. This feature will be tested by observing the normal operation of Messenger during launch as well as during normal communications. CPI provided documentation on our usage.

BP-17

The proposed solution should utilize encryption techniques to maximize protection from unauthorized access or monitoring, including an explanation of the encryption technique utilized.

FT (2.3)

S FoxTalk Messenger

P This requirement is implemented by incorporating the RSA FIPS 140-2 in the software. It can be demonstrating / monitoring a communications session.

BP-18 The proposed solution should accommodate network elements that may already be encrypted at the originating source.

FT (2.3) S FoxTalk P

This capability can be shown by monitoring a communications session for which the network equipment at the remote end encrypts data and which the central site network hardware decrypts the data before it is received by the OpenFox™ system.

BP-19 The proposed solution should allow, when appropriate, NCIC responses to automatically update the NMLETS record.

RFP S TP HFS

P This requirement can be tested by filling in a form for one of the mirrored files and observing that the NIC number appears in the local copy of the record.

BP-20

The proposed solution should utilize nonsequential message and response return techniques to improve performance and timeliness of information.

SG S All P The system as first implemented operated by returning responses in a nonsequential method to improve timeliness. However, NM DPS asked CPI to process responses back to the P-4 in sequential methodology.

BP-21 The proposed solution should enable integration with a recognized, proven, and deployed NCIC-required certification program.

DS S nexTEST P The system provides an interface to the nexTEST certification program. This can be tested by having a user logon, complete the tests and observe that their certification date has been updated.

BP-22 The proposed solution should support the linking of all responses to the queries that triggered them.

MG (5.1.6) S Messenger P The requirement can be tested by running a transaction from the Messenger that routes to multiple data sources and observing that all responses received as a result are linked and presented in a window.



REQ ID



Test Comp


BP-23 The proposed solution should support queries to the New Mexico SOR in conjunction with the standard name query. Was replaced with DOC.

NA NA NA P This requirement was exchanged for the DOC interface.

BP-24

The proposed solution should support and provide a method for NMDPS’s timely receipt and utilization of updates to NCIC (or other) code tables.

SG (3.7) S Code Configurator

P Execute the Configurator to add an entry in the NCIC code table.

BP-25 The proposed solution should support the identification and credentialing of individual users on the local agency interface to NMLETS.

SG (3.6) S US P This requirement can be tested by attempting a logon with and invalid user id or pass word and then logging in with a valid user id and password.

BP-26 The proposed solution should allow automatic printing of messages as specified.

MG (5.5.2) S Messenger P This requirement can be tested by toggling the print ability on the Messenger software.

AN-1 The proposed solution should track every transaction and messaging action (auditing).

SG (5.5) S TR, Op Aid P This requirement can be testing by tracing a message and observing the reported items.

AN-2 The proposed solution should provide all reports in a format that is viewable online. The solution should provide the capability to print any report.

SG (9) S Op Aid P This requirement can be tested by requesting a report and then printing the resultant output.

AN-3 The proposed solution should have online detailed transaction logs for an NMDPS-configurable period of time.

AR (All) S A&R P This requirement can be tested by retrieving transactions with the A&R client software.

AN-4

The proposed solution should provide the capability to export data into any of the standard and commercially available software/report packages or formats such as: .xls, .csv, .txt, PDF, and XML.

SG (9) S Op Aid P This requirement can be tested by requesting reports utilizing the Operator Aid functionality and then exporting the resulting output to other forms such as pdf.



REQ ID



Test Comp


AN-5

The proposed solution should provide the ability to modify report headers, exclude columns, sort by and/or filter on any key data field (including filtering on date range), and save any modified report format for subsequent use.

SG (9) S Op Aid P This requirement can be tested by retrieving a columnar report and then operating on the columns.

AN-6 The solution should provide standardized daily, weekly, and monthly system management and quality assurance reports.

SG (9) S Op Aid P This requirement can be tested / demonstrated by requesting the station activity, configuration, exception and transaction total reports.

AN-7

The solution should provide the ability to create/generate custom or ad hoc reports as determined by the user on any of the data elements in the NMLETS database.

SG (9) AR

S Op Aid A&R

P

This requirement can be tested by executing the Op Aid reporting tool as well as the A&R client software to provide ad hoc capability. Other third party tools can be executed against the A&R database to produce additional ad hoc capability.

AN-8 The solution should provide the ability to generate validation reports on demand. PP S Validation P

NM DPS made a decision to utilize the validation process from Peak Performance. This requirement can be tested by exercising that process.

AN-9 The proposed solution should maintain an audit trail and have the ability to query the audit data based on specific search criteria.

SG (5.5) S TR P The audit trail is maintained by the normal system operation and the Trace program can be executed to test that this feature is operating correctly.

AN-10

The proposed solution should provide both predefined reports and an ad hoc reporting tool (which includes reports on system management and end-user metrics that are available in real time), and it should accommodate changes to these reports by NMDPS staff without vendor intervention.

SG (9) S Op Aid P This requirement can be tested by requesting a GUI screen from Operator Aid and then checking boxes to affect ad hoc reports. In addition, third party tools can be executing against the A&R database.



REQ ID



Test Comp


AN-11

The proposed solution should be capable of supporting and providing reports defined by and to be used by NMLETS auditors. These reports should also be made available in real time via some NMLETS transaction to be authorized via the user provisioning screen.

PP S A&R P This requirement can be tested by executing A&R requesting the appropriate parameters from the Archive database server.

AN-12

The proposed solution should provide a set of standard system and data reports for message switch operations, minimally including the following:

P See below.

• List of transaction types (warrants, missing, etc.) for various agencies run over a user-defined period. TBD S A&R P

The Archive & Retrieval client can be used to provide a report for each device by message key category over a specific requested period of time. This requirement can be tested by requesting this report and analyzing.

• List of all reports under a certain ORI

for a given message key and record type.

TBD C HFS P The hot files application will provide a report for a given ORI by record type.

• Ability to schedule reports. SG (5.10, 9)

S CP, Op Aid P This requirement can be tested by creating a timer report which requests a certain report or by Op Aid and its ability to refresh a report.

AN-13 The proposed solution should be capable of printing any of the reports or other outputs at administratively configurable locations/printers.

MG (3.4) S Messenger P The system supports the ability to print reports and or messages at both the central site as well as the Messenger. In Messenger this requirement can be tested by requesting that a message is printed.

AN-14 The proposed solution should be capable of supporting a reporting function that can minimally provide data by reporting jurisdiction.

AR S A&R P This requirement can be tested by requesting reports by an agency name.

AN-15 The proposed solution should be capable of producing daily activity reports by operator.

ARG (1.3.4)

C A&R P This requirement can be tested through the operation of the A&R client to request a daily activity report by specific operator (user).



REQ ID



Test Comp


AN-16 The proposed solution should be capable of producing an audit trail of all user logon transactions, including password resets.

SG (5.5) S TR, A&R

P This capability can be tested by executing the Trace command and once the data has been exported to A&R by the A&R client.

AN-17

The proposed solution should provide access to audit trails for authorized users, based on configurable security roles. These audit logs should come with robust reporting and search tools.

SG (5.5) ARG

S TR, JQ, A&R P This requirement can be tested by changing the authorization of a user to limit / allow execution of the Trace, Find and A&R capability.

AD-1

The proposed solution should assist in enforcement of the 10-minute rule, that is, upon receipt of an urgent request for hit confirmation, the entering agency must provide a substantive answer within 10 minutes. If no confirmation is received, the system sends another request to the agency and to the designated state control point. If no response is received within 10 minutes, a third request is sent to the agency, NCIC, and NMDPS. If the request is going to another state, the control point for that state and NCIC quality control also receive the request.

DS (9.4.3, Note 1 of App A)

S TP P

This requirement was distilled to adding capability in the transaction processor specific to creating routing and notifications on the second and third hit confirmation requests. This can be tested by sending YQ requests with the request number equal 2 or 3 and observe the email that will be delivered.

AD-2

The proposed solution should support a record validation process by which responsible parties are automatically notified in advance of the need to validate within a specific time frame, records are deleted, and parties are notified of the deletions.

PP C Validation System

P This capability can be tested by exercising the Validation process implemented by Peak Performance.



REQ ID



Test Comp


AD-3

The proposed solution should provide subscription and notification capabilities (e.g., receiving notification that the status of a previous record inquiry has changed).

SG S RIF P

Notifications are a standard function of the Recent Inquiry File system. This requirement can be tested by executing a transaction which will trigger the event and then observing the results. In addition, the NCIC system provides delayed hit responses.

WF-1 The proposed solution should ensure that administrative messages can be sent or routed to:

P

• Users and groups of users.

DS (8) C TP Configurator

P

The transaction processor supports a UM (User Message) which allows a user id as the destination. This can be tested by directing a UM message to a specific user and observe the message delivered to the user. In addition, if the user is not logged in, the message will be held until the user logs on successfully when it will be delivered.

• Agencies and groups of agencies.

DS (8) S TP Configurator

P

This requirement can be tested by configuring an ORI representing an agency, by configuring a group consisting of multiple agency representations and sending a message to these entities. The results can be proved with the Trace command.

• Defined devices. DS (8) S TP Configurator

P This requirement can be tested by configuring a device and then directing a message to it.

• Computer interfaces.

DS (8) S TP Configurator

P This requirement can be tested by configuring a computer interface and then directing a message to it. The results can be confirmed with the Trace command.

• Any of the above within a defined geographic radius or defined group.

DS (8.1.5)

S TP Configurator

P This requirement can be tested by configuring stations with lat and long characteristics and then addressing a message with a radius parameter.

WF-2 The proposed solution should allow for the maintenance of user-defined, reusable group destination codes or lists of users.

SG (3.3) S Configurator P This requirement can be tested be configuring a group of devices into a group or list and directing a message using the group as a destination.



REQ ID



Test Comp


WF-3

The proposed solution should enable configurable routing based on message or transaction type and content. For example, a hit on a wanted person destined for a mobile device is automatically “copied” to a dispatch center device.

DS (TBD) C Configurator TP

P

This requirement can be tested by configuring a device with MDT flag on, executing a transaction which causes a hit and observing the resultant hit being copied to the dispatch center as contained in the alternate station of the configuration.

WF-4

The proposed solution should provide guaranteed message and transaction delivery, including an explanation of how this is accomplished.

FT S FoxTalk P This requirement can be shown by monitoring a FoxTalk session which includes the acknowledgement to a message.

WF-5

The proposed solution should provide for optional message and transaction escalation and alternative delivery. For example, Agency A experiences a power outage, so Agency B is designated to receive Agency A’s messages.

SG (4.3.5, 4.3.7, 4.5)

S CP TP OP

P

There are several methods by which this requirement is delivered. 1-This requirement can be tested by executing a Set Station Route to another destination and then sending a message to the original station. 2-Set Station Copy is executed to provide a copy of all messages at the alternative location. 3-These commands can be executed automatically without operator intervention by setting timer commands.

WF-6

The proposed solution should provide queuing that allows messages and transactions to accumulate for subsequent delivery in the event of connectivity or system downtime; such queues are to be configurable by NMDPS both by duration and message type.

SG S Configurator P This requirement can be tested by setting a station down to accumulate a queue and also setting a threshold on the queue and observing the behavior.

WF-7 The proposed solution should provide a mechanism for making users aware that messages or responses have been received.

MG (3.1.2, 3.1.3)

S Messenger P This requirement can be tested by sending messages to a Messenger device and observing the notification of message received.



REQ ID



Test Comp


WF-8

The proposed solution should allow group queues with the option to delete messages on first read or require that messages be deleted manually.

SG (3.3) S Configurator TP OP

P

After discussion this requirement was distilled to the method of handling a message destined to a group of devices. The standard system provides the ability to configure groups of device in a station class called LIST and the system delivers the message to each of the destinations specified in the configuration of the Group. This requirement can be tested by sending a message to a group code and tracing the results.

WF-9 The proposed solution should allow messages to queue and present them based on message priorities.

SG (3.4) S OP MKE Configurator

P This requirement can be tested by configuring message keys with differing priorities, then queuing the messages and observing that they are delivered in the proper order.

WF-10

The proposed solution should provide for confidential transaction-processing capability; for example, allow an authorized agency administrator to designate an inquiry as “confidential” such that subsequent viewing of messages relating to the inquiry/response can be restricted, including writing audit trail information to a confidential or restricted audit log.

Cancelled D This requirement applies to the Recently Inquired Upon File and has been cancelled by NM DPS because of the possibility of misuse.

WF-11 The proposed solution should allow users to directly update (modify, cancel, locate, clear) records.

DS (7.4.4) S HFS P For hot files this can be tested by executing the various maintenance transactions and verifying the results through the use of queries.

WF-12

The proposed solution should send a create, update, delete, or inquiry message simultaneously to interfaced systems (e.g., NCIC) as appropriate when the equivalent transaction is performed on the local database.

SG (3.4) S HFS P As it relates to hot files, the standard system first stores the record into the local database and then formats and sends a transaction to NCIC if appropriate, to mirror the records.



REQ ID



Test Comp


WF-13

The proposed solution should be enabled to update NMDPS files based on transactions (e.g., locates and NIC numbers) received directly from NCIC.

DS (9.7.4) C HFS P

This requirement can be tested by executing a transaction that causes a local copy in the HotFiles system, tracing the transaction that is process by the HotFiles as well as the response which arrives from NCIC to observe the routing of the messages.

WF-14 The proposed solution should handle the delivery of all messages and responses from all sources to the appropriate end user.

DS (All) S TP P This requirement can be tested by sending messages to each of the interface types.



Technical Requirements

REQ ID Requirement Statement Doc

Source IMP Program / Module

Test Comp Remarks / Notes/ Test Method

IN-1 The proposed solution should utilize a system architecture that is open, nonproprietary, and portable.

DS (6)

S NA P

This requirement is demonstrated through the use of open hardware design. Evidenced by NM DPS purchasing their own back up system to integrate with the proposed solution. The system utilizes Oracle, Unix and IBM hardware.

IN-2

The proposed solution should be adaptive and use extensible architecture for future expansion and scalability without the need for major architectural modifications.

DS (6)

S NA P This requirement is demonstrated through the use of open hardware design. Evidenced by the fact that the Blade center as it exists can be expanded to 14 Blades.

IN-3 The proposed solution should provide system diagnostics, including, but not limited to, error correction and detection.

DS (6) IBM web

S NA P This requirement is demonstrated through the use of open hardware design described in response to section IN-3 of the RFP response as well as the High Availability for OpenFox™..

IN-4

The operational production availability of the proposed solution should be at least 99.999 percent on a 24/7 basis, including a description/justification of how the solution will meet this reliability requirement. NMDPS is interested in a strategy for a clustered and load-balanced environment

DS (6.10)

S NA P

The proposed solution provides one backup server which will take over the production operation if either of the other systems fail. This requirement can be demonstrated by observing the operation of the system since cut over to production.

IN-5 The proposed solution should be capable of supporting test, training, and development environments.

DS (6) S NA P

This requirement can be demonstrated by examining the licenses provided and insuring that the licenses include the production as well as a test, training and development system. The design specification describes the use of the various blades in the hardware configuration.






IN-6

The proposed solution’s processing time should be 2 seconds or less, unless the operation is external to NMLETS; the vendor should include a description of how the solution will meet this response requirement as well as methods for verification of performance.

RFP SG (5.5)

S All Modules P This requirement can be tested by executing transactions, observing the results and utilizing the trace reports to confirm the results.

IN-7 The proposed solution should allow the addition of third-party hardware and software components through open architecture.

DS (6)

S NA P This requirement is demonstrated through the use of open hardware design. Evidenced by NM DPS purchasing their own back up system to integrate with the proposed solution.

IN-8

The proposed solution should provide a description of each system configuration and its ability to meet the availability specification. The vendor should include a system diagram, previous experience achieving these performance specifications, and options.

DS (6) S NA P This requirement is demonstrated by examining section 6 of the Design Specification and insuring that all hardware described in section 6 is delivered and deployed.

IN-9

The proposed solution should provide NMDPS with the right to contract directly with hardware providers for servers if it believes it is in its best interest to do so. A decision to acquire hardware independently of the vendor should not result in a price penalty. Vendors should confirm no price penalty. Vendors should also identify their preferences for a hardware acquisition approach.

DS (6.8) S NA P This requirement is demonstrated through the use of open hardware design. Evidenced by NM DPS purchasing their own backup system to integrate with the proposed solution.

IN-10

The proposed solution should be designed to support the addition of hardware and capacity to accommodate increases in NMLETS throughput and workload over a 5-year period.

DS (6) S NA P

The solution proposed is based upon the IBM Blade Center which includes the ability to house up to 14 Blades. If additional processing power is required another Blade can be added. This requirement can be demonstrated by examining the Blade Center after installation.






IN-11 The proposed solution should be compatible with Internet Protocol (IP) networking standards.

DS (6) S Interfaces P

This requirement can be demonstrated by deploying the hardware architecture proposed and connecting it to the State IP networks. In addition, since the NCIC, Regional systems and Messenger all utilize an IP communications protocol, this requirement can be tested by executing transactions that originate at the Messenger and utilize any of the other IP connections.

IN-12

The proposed solution should support Simple Network Management Protocol (SNMP) and the Web-based tool set for centralized control of the system using an enterprise management platform.

IBM S NA P Demonstrate by examining the software contained in the operating system as deployed.

IN-14 The proposed solution should support TCP/IP addressability for all components throughout the network.

DS (9)

S Interfaces P This requirement can be tested by deploying the Messenger workstations software and observing the operation.

IN-15 The proposed solution should support individual device IDs within agencies (ORI) that can be addressed for the purposes of message routing.

DS (7.3) S TP P This requirement can be tested by adding a device through the use of the station configurator and then addressing a message to that device.

AP-1

The proposed solution should support simple, easy-to-manage, and inexpensive secondary user authentication strategies (e.g., user bingo cards).

NA C NA P

The proposed solution, using SafeID™ electronic tokens was not chosen by NM DPS. At this time there is no alternative solution being considered. Bingo cards cannot be used because of licensing and copyright restrictions. It should be noted that several states are implementing the SafeID™ based solution and it is becoming a standard option in the OpenFox™ system.

AP-2 The proposed solution should support multilevel security to restrict access and control functionality.

DS (7.4.4, 7.4.5)

S US TP

P This requirement is met through the use of the configuration capability and can be tested by configuring a user with / without security roles, executing transactions and observing the results.






AP-3

The proposed solution should allow for the establishment of user accounts and passwords within the parameters of, and should be fully compliant with, the guidelines and specifications established in the FBI Criminal Justice Information Services Security Policy.

DS (7.4.3, 7.4.4)

S US Configurator FoxTalk

P This requirement can be tested by configuring a user with the appropriate parameters.






AP-4

The proposed solution should allow the agency to define how long a password will remain valid within the following secure password attributes established by and in compliance with the FBI Criminal Justice Information Services Security Policy:

• Minimum length of eight characters.

• Not a dictionary word or proper name.

• Not the same as the user ID.

• Changed at a maximum of every 90 days.

• Prevents reuse of the last 10 passwords.

• Shall not be transmitted in the clear, outside the secure domain.

• New Mexico requirement for password to minimally

• include one alphabetical, one numeric, and one special character.

• User account termination should be automatic based on certification date or cancellation by an authorized manager-level command.

SG (4.3.10) S Configurator US

P

This requirement can be tested by configuring a user and then attempting to change the password to a value not compliant with the FBI CJIS Security Policy which includes each of the bulleted requirements. In addition a Messenger communications session can be monitored to observe that the all communications originating from and destined to a Messenger client including passwords is encrypted. In addition the certification date can be configured to expire and a user can execute the nexTEST process to re-establish the certification date.






AP-5 The proposed solution should utilize user profiles to determine system access to the following:

DS (7.4.4, 7.4.5)

S Configurator P

These requirements are met with the capability described in section 7.4.4 and 7.4.5 of the design specification (security roles). This requirement can be tested by configuring a user with roles to include or exclude certain functions / message keys as well as commands. Once the configuration is complete the user signs in and attempts to execute transactions they are authorized to perform and transactions from which they are excluded.

• “Read” access to any data. See Above S See Above P See above

• “Add” access to any data. See Above S See Above P See above

• “Modify” access to any data. See Above S See Above P See above

• “Delete” access to any data. See Above S See Above P See above

• Each function key for which access is granted. See Above S See Above P See above

• Each command for which access is granted. See Above S See Above P See above

• User classification or role. See Above S See Above P See above

• Production (live) or training mode. See Above S See Above P See above

AP-6

The proposed solution should require users to log on to the system before receiving access to any function. The solution should generally support one user, system-wide with agency associations. This sign-on should include, at a minimum:

DS (7.4.5) S User Service

P This requirement can be tested by configuring a user with the ability to sign in from multiple agencies.






• Agency ID (may be user-specified). NA S US P

The agency id does not have to be included. The system will determine from which agency the sign on is occurring and will check to insure that the user can use the agency. This requirement can be tested by having a user try to sign into a device designated at an agency for which they are not authorized.

• A unique user ID and password. SG (3.6) S New- Configurator

P This requirement can be tested by attempting to configure a user with the same id as another already configured user.

AP-7 The proposed solution should allow for the ability to change password at setup, at sign-on, and during the course of a logged-in session.

RFP S US

P

The system requires that a user must be signed in before they can change their password. This requirement can be tested by signing onto Messenger, pulling up the form for password change and executing the transaction.

AP-8

The proposed solution should provide a means for users to recall or reset their password using techniques including, but not limited to:

• Forgot My Password techniques used extensively on Internet sites.

• Challenge questions and answers established during user setup.

• If the user successfully answers the challenge question, provide a temporary complex password and require a new user password upon successful session sign-on.

• Ability for the terminal agency coordinator to reset a password if necessary.

RFP C TBD CP CPI has plans to develop a solution which will meet this requirement and is met with capabilities such as challenge questions in the User Configuration. The solution will be delivered by






AP-9

The proposed solution should be able to be configured such that users are notified of impending password expiration. If a user’s password has expired, the system should prompt the user to change the password at sign-on.

RFP S US Messenger

P

This requirement can be tested by changing the expiration date to nearly expired, sign on and observe whether or not the system presents an impending password expiration notification. Once the password has expired this requirement can be tested by signing on and observing whether or not the system allows any functions or forces the user to change passwords.

AP-10

The proposed solution should store a configurable number of previous passwords for each user and not allow the user to set the new password to any of these previous values.

RFP S US P

This requirement can be tested by attempting a password change to a value used in the last periods. The system normally requires that a use cannot use a password value the same as the last ten occurrences in compliance with the NCIC CJIS Security Policy.

AP-11

The proposed solution should support user roles or classifications that can be dynamically assigned at sign-on to permit users with the proper security level to sign on at any system workstation, local or remote. This classification should be defined by user capabilities.

DS (7.4.4)

S US P

This requirement can be tested by configuring a user with the capability of signing on to any device in the network (not associated to any agency). The user will then attempt to sign on from various agency devices.

AP-12 The proposed solution should afford system administrators the ability to easily update security parameters while the system is online.

SG (3.6) S New-Configurator

P This requirement can be tested by executing the User Configurator.






AP-13

The proposed solution should have a single centralized repository for users and their access information (authentication, authorization, and accounting, also referred to as AAA) so that users have one username and one set of authentication credentials (such as a password) and that all user attributes and authorization are managed in one place, including date of entry. This may be accomplished by using a Lightweight Directory Access Protocol (LDAP) server.

SG (3.6) S New-Configurator

P

The system has its own user repository which is maintained by the use of the configuration tools. This capability may also be used to provide credentialing for other applications. This requirement can be tested by exercising the user configuration tool.

AP-14

The proposed solution should lock user accounts that have been inactive (no sign-on activity) for a specified period of time (NMDPS-configurable 90 days). Such accounts can only be unlocked by a terminal agency coordinator or NMDPS administrator.

RFP S US CP

This requirement can be tested by not accessing a user account longer than the configuration value and then observing the status of the user record. Once this condition occurs the status can be reset by the administrator exercising the user configuration tool and the results verified.

AP-15

The proposed solution should automatically log off users that have been inactive for a specified period of time (NMDPS-configurable hours). Users can simply sign back on to system to resume activity.

SG (3.6) S Fxtalk P

The interface program determines that the user has been inactive longer than the allowed value and will automatically close and disconnect the session. This can be tested by configuring a user with a short inactivity time, connecting, signing on and remaining inactive longer that the specified time. The results must be observed to insure that the session is disconnected.

AP-16 The proposed solution should support Web services.

DS (9.2) S Nlets and Various

P

The system supports the ability to interface to other systems utilizing web services. This feature can be tested by observing the operation of the Nlets communications interface. All other web services interface must be customized and tested individually.

AP-17 The solution should support the use of pointing devices, hot keys, key combinations, buttons, and hyperlinks.

MG

S Messenger P These requirements can be tested by a demonstration of Messenger.






AP-18

The solution should provide for:

• A visual distinction between mandatory and nonmandatory fields.

• Validation of data upon submission of the screen for posting.

• Display of errors on the appropriate screen for the user.

MG

S Messenger P These requirements can be tested by a demonstration of Messenger.

AP-19

The proposed solution’s client application should be Web browser-based and utilize best-of-breed Web form design and usability elements.

DG MG

S Desktop Messenger

P These requirements can be tested by executing the registration and operation of the Desktop / Messenger.

AP-20

The proposed solution’s client application screens should be printable to configurable local or networked printers, using print commands provided by the browser. The proposed solution’s client application screens should be able to be captured using commands provided by the browser.

MG S Messenger P This requirement can be tested by configuring printers within the Desktop / Messenger environment and printing messages on these devices.

AP-22 The proposed solution should support the export or extraction of system code tables for NMDPS use for other systems.

FCG S Configurator P This requirement can be tested by exercising the operation through the use of the Configurator and examining the resultant output.

AP-23

The preferred future NMLETS solution environment is a Unix operating system with an Oracle database, though NMDPS is open to other suggested options.

DS (6) S NA P The operating system of the solution is IBM AIX Unix Operating System and the database management system is Oracle.






AP-24 The proposed solution should provide value-added features normally associated with a mail system, including:

S P

• Saving draft messages for finalizing and sending at a later time. These should be available to other supervisors/users as authorized in the user profile.

MG (5.1.5) S Messenger P This requirement can be tested by exercising the Messenger product.

• Recovering and resending messages at all levels of the system. SG S FIND P

This requirement can be tested by exercising the FIND capability including the use of Playback.

AP-25 The proposed solution should utilize a recognized and commercially available Soundex product.

Oracle S Oracle P The solution utilizes Oracle. The use of soundex was replaced with exact match criteria because of the number of hits being generated using soundex.

AP-26

The proposed solution should minimally be capable of running on the Windows 2000 operating system for the client interface application.

DG (2.1) S Desktop / Messenger

P This requirement can be observed through the operation of the Messenger software by downloading the application onto a system with the Windows 2000 operating system installed.

AP-27

The proposed solution should provide a user interface with a single primary inquiry form or presentation that includes all of the common inquiries (80 to 100 percent of all inquiries available).

DS (Ap-B) C Messenger Forms-Configurator

P This requirement can be tested by exercising the Master Query form.

AP-28

The proposed solution should provide users with a highly integrated set of application modules offering a consistent user interface in order to minimize user training and system administration, including all of the functionality supported in the current NMLETS environment.

TBD F Desktop P

This requirement can be tested by exercising each of the integrated client applications running in the Desktop platform that are currently fully implemented such as; Messenger, Archive & Retrieval, Interceptor, Configurator and Form Configurator.






AP-29

The proposed solution should provide a command line, as well as screen forms, for user entry. Users should be able to enter data on the command line without affecting operations in the forms or other work area.

MG (2.5)

S Messenger

P For the workstation user this requirement can be observed through the operation of the Messenger software.

AP-30

The proposed solution should allow tasks to be entered by keystroke and/or mouse action. However, the system should allow all commands to be initiated by keystroke if desired.

MG (1.3) S Messenger P This requirement can be observed through the operation of the Messenger software.

AP-31

The proposed solution should provide standard GUI items, such as drop-down menus, to make selection easier for frequently used fields, such as message keys, all code tables, and agency IDs.

MG (4.3) S Messenger P This requirement can be observed through the operation of the Messenger software, specifically to show forms with drop down boxes, message keys, ORI’s and code tables.

AP-32

The proposed solution should support “auto complete” functionality for code table lookups as the user begins to enter data in the code table lookup field.

MG (4.3.1) S Messenger P This requirement can be tested by typing into a combo box in a Messenger forms and observing the result.

AP-33 The proposed solution should support automated updates to the user application.

DG (1.1) S Desktop / Messenger

P

This is deployed as a central site application and updates are automatically applied utilizing web start. This requirement can be tested by changing a feature in the software and observing the operation of the software the next time the user launches Messenger.

AP-34

The proposed solution should support pre-fill fields in appropriate pre-formatted screens, eliminating redundant data entry and without impacting the usability.

MG (5.1.6) RFP

S Messenger Form-Configurator

P This can be tested by exercising Messenger and observing the action when a form is opened. YQ casting.






AP-35

The proposed solution should provide quick entry methods such as hot keys to minimize the keystrokes required to perform inquiries. Such hot keys would enable the entry of single data inquiries on the command line, and the inquiry would then be executed according to the hot key used. The single data inquiries include:

• Driver’s license number (DLN).

• License plate number.

• Name.

• identification number Vehicle

MG (2.5) S Messenger P This requirement can be tested by executing the transactions from the Messenger Quick Query Bar.

AP-36

The proposed solution should provide menus to facilitate access to less frequently used functions and to aid users with applications used infrequently.

MG (2.9.1) S Messenger P This requirement can be tested by opening an obscure form utilizing the menu structure.

AP-37 The proposed solution should allow users to move forward and backward to complete data fields.

MG (4.1) S Messenger P This requirement can be tested by exercising Messenger.

AP-38 The proposed solution should allow users to correct spelling errors without having to retype the entire field.

MG S Messenger P This requirement can be tested by exercising Messenger, purposely making a spelling error and correcting it.

AP-39

The proposed solution should provide users with standard form navigation and allow easy movement from one work area to another via mouse or keyboard.

MG S Messenger P This requirement can be tested by exercising Messenger and navigating the forms.






AP-40

The proposed solution should provide hot keys for frequently used functions and associate them with the user profile. Hot keys could be standard key assignments (e.g., F1 through F4), and user keys would be optional key assignments (e.g., F5 through F9).

MG (5.2.1) S Messenger P This requirement can be tested by configuring a set of favorite forms.

AP-41

The proposed solution should enable users to recall (configurable by NMDPS) and resend recently sent messages. The solution should also support Windows cut-and-paste functionality.

DS (9.7,5.4.1)

C HFS Messenger

P

This requirement has been clarified to mean that particularly in the case of repeat missing juveniles the system will not delete missing juveniles but rather keep each record in a history which will be available via a unique query transaction from the Messenger and the response can then be caste into an Enter Missing Form. This can be tested as described above.

AP-42

The proposed solution should enable users to recall a previous hot file entry (recent) form, to update as necessary and to reenter the record as a new entry (frequent reentry of habitual runaways/missing persons, etc.).

DS (9.7.5.4.1)

S HFS Messenger

P See above.

AP-43

The solution should provide default, configurable values for fields based on previous input, referential lookup, or other mechanisms. It should incorporate currently used defaults.

TBD S Form-Configurator Messenger

P This requirement can be tested by configuring a form with default values and then opening the form on Messenger.

AP-44 The solution should provide lookup tables for valid values for fields.

MG S Messenger P This requirement can be tested by opening a form with a drop down box.

AP-45 The proposed solution should maintain all codes in all system code tables with start and end dates.

D This requirement has been deleted.






AP-46

In order to accurately disseminate historical data, the solution should provide for storage of the code value at the time of record data entry for code-driven fields.

D This requirement has been deleted.

AP-47

The solution should translate codes to English-language words or phrases on the output screen and reports for all codes used (e.g., ORI, offense codes, and field names).

RFP S Messenger P

This requirement can be tested by sending a completely tagged XML document to Messenger which has been configured to apply a style sheet to present the message. (Highlight SMT and press F1 to transform)

AP-48

The proposed solution should have the capability to execute scheduled, unattended online system backups without affecting system performance.

DS (6.8, 7.6)

S Unix / Oracle

P This requirement has been tested. Please refer to the Pre-production testing items 6.

AP-49 The proposed solution should have the ability to restore from system backups.

See above S Unix / Oracle


AP-50 The solution should provide robust system backup/archiving tools and strategies.

See above S Unix / Oracle


AP-51

The proposed solution should provide a logging feature that logs entries, changes, and/or deletions to any configuration data (data transaction recovery log).

SG (9.2.8.4) S Op Aid P This requirement can be tested by configuring an element in the system and then utilizing A&R or FIND to view the configuration log.

AP-52

The proposed solution should process data in real time. This means that any parameter change or data change should be done while the system is online. The change should take effect immediately.

SG (3) S Configurator P

This requirement can be tested by configuring each of the configurable elements and requesting reports to indicate the results of the configuration. When a configuration such as a message key or form is changed the operating characteristic can be observed and tested without changing software.






AP-53

The proposed solution should include live, training/test, and development systems. The user’s access level needs to allow the user to be able to select the system that corresponds with the desired system.

DS (6) S All P This requirement can be observed by examining and exercising the hardware platform as deployed including the production environment as well as the test, development and training environment.

AP-54

The proposed solution should support ODBC-compliant relational database technology. Oracle is preferred, but NMDPS is open to other proposed database solutions.

Oracle S Oracle P The database software provided is Oracle. This can be tested by logging into the Oracle software.

AP-55 The solution should provide for access to and manipulation of the data in the database through a standard management system.

Oracle S Oracle P This requirement can be tested by exercising the Oracle11g software.

AP-56 The solution should provide the ability to view the application at various levels, from high-level data flows to the actual code level.

Oracle S Oracle P This requirement can be tested by exercising the tools provided and as described in the RFP response.

AP-57 The solution should provide tools for monitoring and enhancing database organization and performance.

Oracle S P

This requirement is satisfied by various Oracle-provided views of table in the database that are used to collect and access performance and allocation information. Testing can be accomplished by utilizing the Oracle provided statspack which provides a variety of information gathering and display tools for working with the performance and space management characteristics. Or optionally utilizing the tools available in the Oracle Enterprise Manager.

AP-58

The solution should provide tools for database design and development, including documentation, diagramming, normalization, database generation, screen design and generation, report design and generation, and procedure maintenance tools.

Oracle 11g S Oracle P This requirement can be tested by executing the Oracle tools provided in the solution.






AP-59 The solution should provide for the development and maintenance of relational database structures for the support of NMLETS.

Oracle 11g S Oracle P This requirement can be tested by executing the Oracle tools provided in the solution.

PU-1 The proposed solution should have the ability to interface to an ad hoc reporting tool that allows trained users to create reports from data.

Oracle 11g S Oracle P This requirement can be tested by executing the Oracle tools provided in the solution as well as accessing the databases with other third party tools.

PU-2

The proposed solution should have a report batch monitor that controls the number of reports that may be run at a given time for each server.

Oracle 11g S Oracle F This requirement is tested by utilizing the OpenFox™ Report Monitor Subsystem Application that provides management and control of report programs.

PU-3 The proposed solution should have a report scheduler that can schedule reports to be automatically run at user-defined times.

Oracle 11g S Report Monitor Application

P This requirement can be tested by executing the Oracle tools provided in the solution, Oracle Express Manager JOBS.

PU-4

The proposed solution should provide the ability to load a Microsoft Word file onto the system that is then available as a bulletin to advise of system updates and other information.

TBD C TBD D This requirement has been deleted

PU-5 The proposed solution should support reports, both of real-time and snapshot data, that are publishable to an intranet or the Internet.

Oracle 11g S Oracle P This requirement can be tested by exercising the scripts to export data and push that data to another server which could be an internet web site application.

IT-1 The proposed solution should be capable of interfacing with NCIC system files, including the FBI NICS Denied Persons file.

DS (9.1)

S TP Messenger

P This requirement can be tested by opening the appropriate form, filling it in, sending it to the system and observing the results.






IT-2

The proposed solution should be capable of harvesting NCIC entries and messages for data to generate New Mexico Criminal Justice Information System (CJIS) (and other future) records. This may be in the form of a tool set that enables the harvesting of data from transactions for the purpose of populating other data and files, as appropriate.

DS (9.7) S TP HFS

P

This requirement can be tested by executing a transaction such as a wanted person entry which will populate the local hot files as well as send the entry to NCIC. Once NCIC returns a positive response the local copy of the record can be examined to see that the NIC number was harvested.

IT-3 The proposed solution should be capable of interfacing with Nlets.

DS (9.2) S P

This requirement can be tested by sending messages to Nlets and receiving messages from Nlets. The connection can be monitored to observe the communications in real time. The trace command can be used to show the communications from an historical view.

IT-4 The proposed solution should be capable of interfacing with New Mexico CJIS.

DS (9.8) C CJIS P The interfaces will utilize SQLnet capabilities and will reuse some of the existing database procedures. This requirement can be tested be executing the standard CJIS transactions.

IT-5

The proposed solution should be capable of interfacing with the New Mexico CCH system, and creating queries to New Mexico CCH first and then III.

DS (9.8) C TBD P The interfaces will utilize SQLnet capabilities and will reuse some of the existing database procedures. This requirement can be tested be executing the standard CCH transactions.

IT-6

The proposed solution must be capable of seamlessly interfacing with all current NMLETS interfaces on the first day of implementation (i.e., CAD, RMS, mobile data terminal [MDT], local systems).

DS (9.5) C P4IF P

This requirement can be tested by operating the existing P-4 switch as a regional system and executing transaction from devices connected to the P-4 system. In addition, testing will be required with the majority of these systems in order to assure proper operation.

IT-7 The proposed solution should be capable of interfacing with the NMDPS network-attached storage (NAS).

DS (6) S Hardware P

This requirement has been waived as the NM DPS agreed to purchase the SAN from CPI. This requirement can be tested by observing the operation of the SAN and all applicable applications such as; Message Switch and Database applications.






IT-8

The proposed solution should be capable of interfacing with Nlets photo sharing in conjunction with NMDPS and Motor Vehicle Division (MVD) photos.

DS (9.2, 9.3)

S/C

Nlets IF TP Messenger MVD IF

P

NM DPS has moved the in-state MVD image server to the MVD system. In state photo capabilities will be retrieved from the MVD interface. This requirement can be tested by requesting a photo in-state as well as from one of the States on the Nlets network that supports the sending of Photos.

IT-9 The proposed solution should be capable of interfacing with New Mexico MVD and photo sharing.

DS (9.3) C MVD IF P NM DPS has moved the in-state MVD image server to the MVD system. In state photo capabilities will be retrieved from the MVD interface. This requirement can be tested by requesting a photo in-state.

IT-10 The proposed solution should be capable of interfacing with the CCW files.

DS (9.8) C CJIS IF P This requirement is met through exercising existing calls to the database and it can be tested by running queries which will route to the interface.

IT-11 The proposed solution should enable external system interfaces to send properly formatted NCIC messages and transactions.

DS (9.1) S Regional IF P This requirement can be tested by submitting an NCIC transaction from a Regional interface destined to NCIC and observing the resultant output.

IT-12 The proposed solution should support the Global Justice XML Data Dictionary (GJXDD), GJXDM, and the NIEM XML data model.

DS (9.2.8) S Nlets IF MVD IF

P

This requirement can be tested by sending and receiving GJXDM messages from / to Nlets. The results can be monitored real time or historically. The system utilizes style sheet processing to transform the messages to a format useable by the state systems.

IT-13 The proposed solution should be able to query/exchange data in the NIEM reference model format.

DS (8.1.1.2.1)

S TP IF

P The system supports any form of XML document through the use of style sheet processing for transformation. The style sheets are configured and then configured into the appropriate message key.

IT-14

The proposed solution should support electronic data access to third-party systems for query/exchange (for example, Web services, ODBC, data warehouse/flat file, API).

DS (9) S Interfaces P This requirement can be tested by exercising the custom interfaces such as supplied to interface to regional systems.

IT-15 The proposed solution should explain the approach to Web services.

DS 9.2 DS 9.3

S Nlets IF MVD IF

P The approach to the web services requirement is documented is sections 9.2 and 9.3 of the design specification document. This document can be reviewed to explain the CPI approach.






IT-16 The solution should support authentication of an electronic report/interface data source.

DS (9.5) S Interfaces P

The system has a variety of methods of identifying external systems; for example the regional interfaces are identified via an IP address and port. The NCIC system is identified by IP and port whereas the Nlets interface is identified by IP address and passwords. The remote databases such as CCW, the interface process uses a logon with credentials provided by NM DPS which allows connections to the database.

IT-17 The proposed solution should have the ability to search multiple external systems and/or databases via a single query.

SG (3.4) S TP Configurator

P This requirement can be tested by configuring a message key transaction which will be spawned to multiple data sources and observing the resultant output.

IT-18 The proposed solution should have the ability to receive and respond to queries from authorized external systems and/or databases.

DS (9) C TP OP Interfaces

P This requirement can be tested by executing transaction from interfaces or receiving responses from interfaces.

IT-19 The proposed solution should have the ability to access mug shots and other image information stored in any other NMDPS repository.

DS (9) MG (4.6.1)

C Interfaces Messenger

P

Currently the MVD, Nlets, CCW/DOC, CCH and NCIC interfaces can respond with images. The system supports the creation of new interfaces and will support protocols which are able to send and receive images. In addition, the Messenger software has the ability to include images in messages that are located anywhere on the local system. Per DPS request we are providing CCH, DOC and MVD.

IT-20 The proposed solution should have the ability to access other documents or images stored in a specified repository.

MG (4.6.1) S Messenger P This requirement can be tested by having Messenger import an image from a directory on the PC and operating on it.

IT-21 The proposed solution should have the ability to retrieve and route images stored in a specified repository.

MG (4.6.1) S Messenger P This requirement can be tested by having Messenger import an image from a directory on the PC and operating on it.

IT-22 The proposed solution should have the ability to retrieve and route other documents or images stored in a specified repository.

MG (4.6.1) C Messenger P

This requirement can be tested by having Messenger import an image from a directory on the PC and operating on it. In addition, this requirement can be tested by retrieving a document other than an image and attaching it.






IT-23 The proposed solution should afford the user the ability to save or print images regardless and independent of the response.

MG (3.4) S Messenger P This requirement can be tested by printing the images received from different sources such as Nlets and NCIC.

ST-1

The proposed solution should support “recent inquiry” functionality wherein new inquiry data is compared with similar inquiry types for the past 10 days (time period configurable by NMDPS). Information about any matches on similar inquiries run with the same data (data element, inquiring agency and user, and any notes associated with the inquiry) should be returned to the user.

DS (9.9) C Recent Inquiry File

P This requirement can be tested by executing the same query transaction and observing whether a recent inquired hit is produced.

ST-2 The proposed solution should support the addition of inquiring user notes to a recently conducted inquiry (e.g., license plate, DLN).

NA D This capability has been deleted.

ST-3

The proposed solution should support the ability of the end user to mine log, activity, and transaction files to recall actions and responses for a period of time configurable by NMDPS.

MG (3.5) SG (7.1) AR

S Messenger JQ A&R

P This requirement is met with several capabilities. The Messenger, the Message Switch and the Archive & Retrieval all meet this requirement. The requirement can be tested by exercising these capabilities.

ST-4

The proposed solution should be capable of harvesting data from a response (e.g., the registered owner name and date of birth from a vehicle or plate inquiry) and auto-generate another inquiry (e.g., a standard name inquiry to NCIC) based on that data element.

DS (9.2.8.7, 9.3.3.12)

C TP Configurator

P This capability can be tested by running a vehicle plate inquiry to a state that returns a fully tagged response.






MA-1

The proposed solution should provide communication link self-monitoring capabilities such that it identifies when a connection is unavailable and notifies the designated system administrator of the outage by predefined notification means (e.g., pager, telephone, e-mail).

UOG (3.2) C HA P

This requirement can be tested by dropping the connection from one of the interfaces being monitored with HA and observing whether or not the interface turns red. In addition, SAM will send a remote notification via email when a queue being monitored exceeds a queue threshold.

MA-2

The proposed solution should provide for software upgrades/maintenance that do not affect the production system (no downtime) in a load-balanced environment.

SG (3, 4.1.1.2)

S Configurator CP

P This capability can be tested by changing a source program and executing a Rest Computer Program

MA-3

The proposed solution should include the necessary company and staff resources to implement the proposed system, including a detailed explanation of these resources and plans in project management and staffing plans included in the management response.

ALL S NA P This requirement will be met with the project team. The only test is whether or not the objectives of the project are met in a successful, timely and professional manner.

MA-4

The solution should enable every component of the message switch system to be modified by system administrators to meet changing federal and state standards without the need to contract with a vendor to make changes.

SG (3) S Configurator P This requirement can be tested by exercising the configuration capabilities in the OpenFox™.

MA-5 Vendors should provide an explanation of their service and support philosophy, how it is carried out, and how success is measured.

SAM S NA P Please see the explanation of Pre-Production Testing item number 5.






MA-6

The proposed solution should provide ongoing services and support, including, but not limited to, the following: toll-free 24/7 customer service, annual training classes, an online customer service Web site, and online software maintenance.

HDP S NA P This requirement is met with our Help Desk system support and there is no real test other than results over a period of time once the system has been placed into production.

MA-7

The proposed solution should provide a thorough description of help desk services, including dial-in, Web support, and ongoing maintenance.

HDP S NA P

This requirement can be tested by visiting the CPI headquarters and observing our Help Desk personnel in action. As stated earlier the Help Desk is actively monitoring the operation of the system with SAM (System Automated Monitoring). In addition tools such as Bomgar are used which allow Help Desk personnel to take over the operation of a client PC which aids dramatically in debugging problems associated with the workstation software.

MA-8

To maintain configuration integrity, the proposed solution should support configuration control for all configurable elements, including auditing, rollback, roll-forward, and configuration change transactions with the ability to both import and export configurations.

SG (3) S Configurator P

This requirement is met by the export and import features of the standard configurators and the rollback capability of the Form Configurator. This requirement can be tested exercising these capabilities.

MA-9 The proposed solution should comply with established NMDPS and State of New Mexico technology standards and policies.

NA C System Hardware

P This requirement can be observed by examining the hardware platform when it is deployed to insure compliance.

MA-10 The solution should be compliant with all standards and policies outlined in subsection IV.B of the RFP.

RFP S All P This requirement is met with the implementation of the OpenFox™ solution as described in the Design Specification and can be observed to insure the proper operation of all agreed upon components.






MA-11 The solution should comply with FBI Criminal Justice Information Services Security Policy (V4.4), June 2007 or latest.

RFP S Messenger US

P

Many aspects of the NCIC CJIS Security Policy can be tested by maintaining the user records both through the use of configurations as well as user input. In addition the encryption can be demonstrated and described to show compliance. However, the NM DPS did not accept our proposal for advanced authentication which is being implemented in several states such as Oklahoma, Arkansas and Alabama.

MA-12 The proposed solution should comply with NCIC response time and performance requirements.

NCIC Manual

S Ncitcp TP OP

P This requirement can be tested by executing NCIC transactions and observing the results physically as well as through the use of the Trace capability which records all event times.

MA-13 The proposed solution should meet delivery and transmittal requirements for NCIC 2000 and Nlets.

NCIC Manual

S

TP OP Configurator Nlets IF NCIC IF

P

This requirement can be tested by executing all NCIC and Nlets transactions to insure proper operation. The test results can be observed physically as well as through the use of the Trace capability which records all event times.

MA-14 The proposed solution should use standard NCIC codes and descriptors.

SG (3.7) S Configurator Messenger TP

P

The Configurators are used to maintain the codes and descriptors. This requirement can be tested by attempting to input something other than proper NCIC codes in Messenger forms as well as sending transaction from regional system to test TP which must also edit the transactions.

MA-15 The proposed solution should comply with NIEM and GJXDM standards.

DS (9.2, 9.3)

C TP OP Interfaces

P

The system complies with GJXDM and NIEM standards by providing the capability to apply style sheets to XML documents. From a GJXDM perspective, the requirement can be verified by monitoring interfaces such as Nlets and MVD which utilize these XML standards.

MA-16

The proposed solution should provide a training environment, especially for hot file entry and maintenance. This environment should simulate complete hot file entry and maintenance functionality, validation, and response, without sending to NCIC.

DS (6.10) S Test System

P This requirement is met by providing a test system which connects to the NCIC Test Region. This can be tested by starting the OpenFox™ test system and sending transactions to NCIC as well as the local hot files.






MA-17

The proposed solution should provide access to online system help files that describe fields, forms, and data requirements, as well as procedures from system documentation.

MG (4.7) DG (4.3.2.4)

S Messenger P This requirement can be tested by utilizing the Messenger Help system.

MA-18

The proposed solution should provide access to online NCIC manual files that describe fields, forms, and data requirements, as well as procedures and automatic updates.

MG (4.7) DG (4.3.2.4)


MA-19

The proposed solution should provide access to online Nlets manual files that describe fields, forms, and data requirements, as well as procedures and automatic updates.

MG (4.7) DG (4.3.2.4)


MA-20

The proposed solution should provide access to online NMLETS manual files that describe fields, forms, and data requirements, as well as procedures and automatic updates of the manual by NMDPS administrators.

MG (4.7) DG (4.3.2.4)

C Messenger P This requirement can be tested by accessing the NMDPS manuals in the Messenger.

MA-21 The proposed solution should provide the ability to query the NMLETS manual and to allow automated updates by NMDPS administration.

MG (4.7) DG (4.3.2.4)

C Messenger P This requirement can be tested by accessing the NMDPS manuals in the Messenger.

MA-22 The proposed solution should provide a detailed user-training program and include a syllabus of each class and sample training manual.

TBD C Training Plan

P This requirement is met with the training plan and the execution of the plan to customer satisfaction.






MA-23

The proposed solution should provide sufficient training for the number and type of users described in the training plan outlined in the Management Response section of the proposal. This includes providing training during evening shifts. Vendors should provide a detailed definition of the number of training classes, class duration, class size, and class location.

TBD C Training Plan

P This requirement is met with the training plan and the execution of the plan to customer satisfaction.



2.5 Signature Block

The system is accepted and warranty will begin on 05/15/2011 with the following conditions and understanding that CPI will continue to work on the issues that have been marked either CP (Conditional Pass) or F (Fail). The following requirements are marked as deleted by mutual agreement: WF-10, AP-45, AP-46, PU-4 and ST-2. The following requirements are marked as Conditional Pass with the understanding that CPI will deliver as soon as possible: AP-8 and AP-14. The following requirements have been marked as Fail with the understanding that CPI will deliver as soon as possible: PU-2. For New Mexico Department of Public Safety For CPI Mr. John Oliver Mr. Lorne Sawatzky Project Manager, Information Technology Division President _______________________________________ ___________________________________________ Date: ______________________ Date: _____________________

NMLETS Replacement Project Traceability Matrix - … · Computer Projects of Illinois, Inc. NMLETS...

Documents

Transcript of NMLETS Replacement Project Traceability Matrix - … · Computer Projects of Illinois, Inc. NMLETS...