Page 172 - Automated Fingerprint Identification Systems (AFIS)

BUYING AN AFIS SYSTEM: THE BASIC DOCUMENTS NEEDED 157

documents typically go through several iterations before they are deemed clear
enough to release to vendors—the process from first draft to final document
can take several months to complete.
To reduce the possibility of creating ambiguous statements within the
requirements specification document, the team assigned with generating the
document should meet with the contracting officer assigned to the project to
discuss rules and requirements that are typically contained in standard terms
and conditions sections of the RFP package to ensure that requirements spelled
out in the requirements spec and subsequent SOW do not conflict. In some
instances, items that may logically be contained in the requirements specifica-
tion document may already be covered in the government’s standard con-
tracting package. In those instances, the requirements document should
reference the specific section and paragraph in the terms and conditions that
are part of the RFP package.
The requirements specification document is where you specify the capabili-
ties of the system to be delivered and relate them to the automated and semi-
automated workflows you will be following. It should echo the ConOps but have
more granularity and detail. The document typically has the following outline:

1. Introductory material, including table of contents, change history, reference
documents, standards, and other high-level information.
2. Contextual information, such as the current environment and interfaces,
planned changes in policy, interfaces, volumes of transactions, etc.
3. Functional performance (throughput, response time, availability, etc.), inter-
face protocols and data rates, and storage requirements, using “WILL”
statements for informational purposes and “SHALL” statements for system
requirements. This can be arranged by workflow, by functional area, or by
subsystem.
4. Appendices, as appropriate, including a glossary of terms and abbreviations.

The requirements should be labeled with their evaluation classification so the
vendors know which ones to spend additional time responding to. The classes
are as follows:

• Mandatory requirements: those requirements that the vendor must address
in their proposal. Evaluation of mandatory requirements is generally on a
pass/fail basis. Failure to address any one mandatory requirement may result
in the proposal being removed from consideration.
• Rated requirements: those requirements for which a vendor may present a
solution that can be rated as providing a more creative approach to the
requirement than was anticipated. Developing rating schemes that can be