Documents
ICE ICM Statement of Objectives
Mar. 2 2017 — 12:51 p.m.

Immigration and Customs Enforcement (ICE)
TECS Investigative Case Management (ICM)
Statement of Objectives
U.S. ICE Office of the Chief Information Officer (OCIO) and Homeland Security
Investigations (HSI)
May 1, 2014
Version 1.0
Statement of Objectives
Version 1.0
Page: 0

Table of Contents
1. Purpose...................................................................................................................................................... 3
2. Scope ......................................................................................................................................................... 3
3. Program Execution.................................................................................................................................... 3
4. Background ............................................................................................................................................... 5
4.1 Program Organization ......................................................................................................................... 6
4.2 HSI Investigative Case Management Ecosystem View ...................................................................... 7
5. Mission Capabilities for the ICM System ................................................................................................ 8
5.1 Case Creation and Management ......................................................................................................... 9
5.2 Subject Record Management .............................................................................................................. 9
5.3 Data Migration of Existing Legacy TECS Subject Records ............................................................. 10
5.4 Reports of Investigation .................................................................................................................... 11
5.5 Notifications...................................................................................................................................... 11
5.6 Interfaces ........................................................................................................................................... 12
5.7 Flexible Linking of Cases, Documents, and Subject Records .......................................................... 12
5.8 User Control of Access to Case-Related Information ....................................................................... 12
5.9 Transfers of Users, Cases, and Subject Records ............................................................................... 13
5.10 Searching Structured and Unstructured Data Across Document Types ......................................... 13
5.11 Agent Work Hours .......................................................................................................................... 14
6. Technical Capabilities for the ICM System ............................................................................................ 14
6.1 Hosting Environments ...................................................................................................................... 14
6.2 Key Performance Parameters and Maintainability ........................................................................... 15
6.3 Measures of Effectiveness ................................................................................................................ 16
6.4 User Provisioning.............................................................................................................................. 17
6.5 Single Sign On .................................................................................................................................. 18
6.6 Interfaces ........................................................................................................................................... 18
6.7 Data Migration .................................................................................................................................. 21
6.8 ICE Data Warehouse......................................................................................................................... 23
6.9 Security and Privacy ......................................................................................................................... 23
6.10 Data and Licensing ......................................................................................................................... 23
7. Implementation and Management ........................................................................................................... 24
7.1 Development, Test, and Deployment Approach ............................................................................... 24
7.2 Service Desk Support. ....................................................................................................................... 25
7.3 Maintenance Support ........................................................................................................................ 26
7.4 Training Strategy .............................................................................................................................. 26
7.5 Systems Engineering Lifecycle Documentation ............................................................................... 26
Statement of Objectives
Version 1.0
Page: 1

7.6 Project Management ......................................................................................................................... 26
7.7 Key Personnel ................................................................................................................................... 27
8. Applicable Documentation ..................................................................................................................... 28
Appendix A - List of Acronyms ................................................................................................................. 30
List of Figures
Figure 1: HSI Investigative Case Management Ecosystem View ................................................................ 8
Figure 2: CORE HSI Investigative Case Management Processes ................................................................ 9
Figure 3: Example of One-to-Many Relationships in HSI Subject Records............................................... 10
Figure 4. HSI User Provisioning for the ICM System ................................................................................ 17
List of Tables
Table 1. ICE TECS Modernization Program Hosting Environments ......................................................... 14
Table 2. KPPs for the ICE TECS Modernization System ........................................................................... 15
Table 3. ICE TECS Modernization System Interfaces ............................................................................... 18
Table 4. Legacy TECS Data to be Migrated to the ICM System ................................................................ 21
Table 5. Tier 2 and 3 Performance Requirements....................................................................................... 26
Statement of Objectives
Version 1.0
Page: 2

1. Purpose
The purpose of this Statement of Objectives (SOO) is to obtain a Commercial Off-the-Shelf 1 (COTS)based, web-enabled Investigative Case Management (ICM) system. The ICM system will support the
U.S. Department of Homeland Security (DHS) Immigration and Customs Enforcement (ICE)/Office of
the Chief Information Officer (OCIO) and Homeland Security Investigations (HSI) mission, and will
improve HSI’s ability to investigate, manage, and report on law enforcement and intelligence activities.
Within the context of this solicitation, the ICM system is defined by the following criteria:
•
•
•
•
•
Mature COTS-based, web-enabled solution that can achieve the aggressive schedule of delivering
a production ready solution for formal integration testing within six months after contract award
and that can be ready for initial operation no later than September 30, 2015
System that can be configured or minimally customized to support the unique requirements of the
ICE/HSI investigative law enforcement agency
System that can integrate into the DHS and ICE enterprise infrastructure
System that can interface with other specified systems that are internal and external to ICE and
DHS via the ICE Interface Hub (see Figure 2 and Section 6.6)
System that can interface with the ICE Data Warehouse (see Section 6.8).
2. Scope
The ICM system shall meet ICE/HSI requirements expressed at a high level in this SOO and in detail in
Exhibit A. The Offeror shall provide the services and software to support the requirements outlined in this
SOO in accordance with the Offeror’s proposed Performance Work Statement (submitted by the Offeror
in response to the request for proposal [RFP]), which will be incorporated into the contract at the time of
contract award. The Government encourages Offerors to propose the most innovative, cost-effective
solution and implementation methodology to achieve the desired objectives and results within the context
of this solicitation. The Government’s objective is to acquire an ICM system that:
•
•
•
•
•
•
•
•
Creates and manages ICE/HSI investigative cases and documents
Creates and manages HSI subject records that include information related to person, vessel,
vehicle, aircraft, business, and other thing(s)
Links subject records to reports of investigation (ROIs) and investigative cases
Creates and manages lookout records shared with Custom and Border Protection (CBP)
Performs investigative research via system interfaces both internal and external to ICE and DHS
Creates and manages case statistics (i.e., arrests and seizures)
Captures administrative data (such as agent work hours on cases)
Generates reports on case-related data.
The Offeror shall implement, integrate, and test the ICM system in a Government facility and have the
ability to provide operations and maintenance (O&M) support after Initial Operating Capability (IOC)
and Full Operating Capability (FOC).
3. Program Execution
To successfully execute this SOO, the Offeror’s team must integrate with the existing project teams
supporting the ICE TECS Modernization program to promote seamless interoperability across the teams
1
In the context of this procurement, the term “COTS system” means a previously developed and deployed system that requires
minimum new development to meet ICE ICM system requirements.
Statement of Objectives
Version 1.0
Page: 3

while fostering transparency and information sharing. The other development teams have been focused on
profiling and migrating the data from the legacy TECS environment into a target database, identifying
data that needs to be integrated into the Offeror’s solution, developing data services to support the
interfaces with external systems, and developing documentation to support DHS system life cycle.
The Offeror shall propose a work schedule with timing and associated milestones required to achieve IOC
in four consecutive defined time phases of work (i.e., Phases 1 – 4 below), the length of each phase will
depend on an individual Offeror’s proposed solution. The Offeror’s work schedule shall be formatted
according to the RFP’s instructions to the Offeror regarding submission of a Contractor Work Breakdown
Structure (CWBS).
The Offeror’s work shall be executed in phases as follows.
Phase 0 (optional)-Proof of Concept: The Government has the option to award multiple contracts. The
base period of each contract will consist of a two (2) month proof of concept period to support further
functional and technical review of each Offeror’s solution. During this period, the Offeror will build a
proof-of-concept based on the operational flow described in Exhibit B. To minimize external
dependencies, development and hosting shall occur at the Offeror’s location during the 2 month base
period. The functionality developed will need to be incorporated as part of the overall solution and not be
developed as “throw away” code. At the conclusion of the base period, the Government will exercise
Option Period 1 of the contract which is determined to offer the best chance of successful completion. No
further options will be exercised on the other contracts.
The Government will use the proof of concept to validate and independently verify that the Offeror’s
solution can successfully navigate the operational flows referenced in Section 5 of this SOO and
described in Exhibit B. The Government will also use the proof of concept to help verify that the Offeror
can fulfill the ICM system Capabilities Matrix in the RFP as outlined by the Offeror in their response to
the RFP. Any functionality developed in this time frame shall be incorporated as part of the overall
solution. The proof of concept must demonstrate to the Government that the Offeror has a significant
potential to successfully continue with configuration, development, and implementation of the ICM
system solution.
Phase 1- Requirements Confirmation and Baseline Installation: The Offeror shall rapidly install their
ICM system solution in the DHS/ICE development and test environment, or other environment proposed
(see Section 6.1). The ICM system shall be configured and operable to the baseline level of functionality
and technical capability representative of the COTS system solution installed at other customer facilities,
as depicted in their past performance statements, and as documented in the Offeror’s assessment of its
baseline solution’s capabilities (reported by the Offeror in the response to this RFP).
Phase 2-Baseline Gap Analysis: The Offeror shall perform a gap analysis of the baseline capabilities as
installed in the first phase versus the required IOC capabilities. This gap analysis will be performed with
the Offeror’s resources and those of the ICE TECS Modernization program, for example the HSI users.
Due to schedule constraints, the Offeror may propose overlapping Phase 1 and Phase 2 as deemed
appropriate. However, Phase 3 should not commence until the Offeror develops a plan of action for
resolving the gaps identified in this analysis and the Government approves said plan.
Phase 3-IOC Development and Configuration: The Offeror shall configure and develop the IOC
capabilities as documented in the Baseline Gap Analysis and approved by the Government. This phase
and the preceding phases 1 and 2 will end no later than six months after contract award and the end of this
phase will constitute the “code freeze” milestone for IOC in which all ICM system development and
configuration work is complete.
Phase 4-IOC Integration and Testing: This phase is targeted to end no later than six months after the
completion of Phase 3. This phase of work will consist of extensive integration testing, system testing,
performance testing, user acceptance testing, and stress testing of the ICM system solution with the ICE
Statement of Objectives
Version 1.0
Page: 4

interface hub, ICE Data Warehouse, and other ICE TECS Modernization system components required for
the IOC as defined in Exhibit A. The Offeror shall participate in all levels of integration and testing as the
overall ICE TECS Modernization system progresses to IOC. Specifically, the Offeror shall assist in
analyzing problems discovered during all levels of integration and testing. The Offeror shall correct errors
and shortfalls (example of shortfall is not meeting performance requirements) in the ICM system during
all levels of integration and testing.
Note: Phases 1 through 4 constitute Option Period 1 of the contract and are included in the Firm
Fixed Price portion of the CLIN structure.
FOC Capabilities. FOC capabilities and other system enhancements, if required, will be accomplished
through optional System Enhancement CLINs for development, configuration, integration, and testing.
This work will be accomplished on a Labor Hour (LH) basis as the exact scope of the FOC capabilities is
undeterminable before completion of IOC. Some FOC capabilities may have been met in the offeror’s
base system.
Maintenance of the ICE System Solution. The Offeror shall provide their approach for maintenance of
the ICM system solution. This approach shall include the Offeror’s basic approach to ICM system bug
fixes/patches, routine maintenance and upkeep of the ICM system solution, on licenses and upgrades on
the Offeror supplied products associated with the ICM solution, and to upgrade frequency to the installed
ICM system solution. The approach shall also stipulate the level of commitment of the Offeror in
maintaining the ICM system solution in perpetuity or in transfer of the ICM system license to the
Government and in training the Government or designees in this maintenance capacity.
Transition Out The Transition Out phase will provide the Government with a Transition Management
Plan (TMP) 90 calendar days prior to the completion of the period of performance (POP). The Offeror
shall provide their approach for supporting export of all ICE data in the ICM system in a format usable
by, and approved by, the Government to a different product if desired by the Government. The technical
activities included as part of the TMP shall consist of the following:
•
•
•
•
•
•
Provide inventory and orderly transfer of all Government Furnished Equipment/Property
(GFE/GFP), software and licenses
Update and transfer of documentation currently in process
Transfer of all ICE-specific software code in process
Coordinate the transition process with DHS/ICE IT personnel
Fully support the transition of ICE-specific requirements to any successor contractor
Execute the TMP transition activities with no disruption in operational services.
4. Background
ICE is the largest investigative agency within DHS. Formed in 2003 as part of the Federal Government's
response to the September 11, 2001 (9/11) attacks, ICE's primary mission is to protect national security,
public safety and the integrity of the U.S. borders through the criminal and civil enforcement of federal
laws governing border control, customs, trade, and immigration. ICE employs approximately 19,000
employees in over 400 offices worldwide with an annual budget of more than $5 billion. The agency's
law enforcement authorities encompass more than 400 U.S. Federal statutes that ICE enforces in its
commitment to ensuring national security and public safety.
HSI, a critical asset in the ICE mission, is responsible for investigating a wide range of domestic and
international activities arising from the illegal movement of people and goods into, within, and out of the
United States. HSI investigations cover a broad range of areas with a particular emphasis on border
related crime. This includes national security threats, financial and smuggling violations, counterproliferation, weapons trafficking, financial crimes, import fraud, human trafficking, human smuggling,
Statement of Objectives
Version 1.0
Page: 5

narcotics trafficking, gang enforcement, child exploitation/pornography, child sex tourism, document
fraud, critical infrastructure protection and immigration benefit fraud. HSI is responsible for modernizing
the case management, subject record management and the interface functionality components of the
legacy TECS system. This project will allow HSI to continue to successfully conduct criminal and
administrative investigations toward its law enforcement mission.
TECS was developed in 1987 by the U.S. Customs Service as an umbrella system to support the business
activities related to border crossing and investigative case management. Modernization of the
functionality related generally to border crossing activities is currently being modernized by Customs and
Border Protection (CBP), and is outside the scope of this effort. The ICE TECS Modernization program
focuses, in general, on the investigative case management activities and ancillary functionality necessary
to support the business requirements of HSI. The present system, also known as legacy TECS, is currently
administered by the CBP Office of Information Technology (OIT). While the border crossing components
(under modernization by CBP) and the investigative case management components (being modernized by
ICE) are distinct modernization efforts, collaboration and interoperability of both the solutions and
modernization efforts are essential to ensure mission success.
Legacy TECS (TECS was the acronym for the legacy Treasury Enforcement Communication System) is
currently the backbone for recording, searching, managing, and maintaining law enforcement actions
taken by CBP and ICE. Current TECS functionality does not allow interoperability among databases,
modern interfaces for system users, or current security best practices.
4.1 Program Organization
The ICE TECS Modernization program is conducted under the direct oversight of ICE OCIO and the
Executive Sponsor, HSI. The program is organized into an ICE TECS Modernization Program Office and
a series of Integrated Project Teams (IPTs). Each IPT focuses on a critical portion of the program. An IPT
comprises a team leader who is accountable for the team mission, objectives and deadlines, and IPT
members who are key stakeholders with responsibility for a portion of the IPT objectives.
IPTs will be created, maintained and/or decommissioned based on program progression. Continuous
coordination and communication between the various teams are essential and critical to the success of the
program. The IPT structure provides defined roles and responsibilities to ensure accountability, enhance
communication within the project, and enable more effective tracking of program goals and objectives by
management. The IPTs work together to ensure that risks and issues are identified, addressed, and
elevated when necessary. The Offeror shall provide information (e.g. status reports) and attend weekly
reoccurring IPT meetings as required. Additionally the Offeror shall conduct trade studies and analysis in
support of the IPTs as requested by the Government. The IPTs are currently organized as follows:
•
•
•
•
Requirements. Responsible for managing requirements including refinement, categorization, and
creation of new requirements where necessary.
Interfaces. Responsible for implementing internal and external interfaces, establishing and
maintaining communication with interface partners, and ensuring interface requirements are
documented properly.
Data Migration Team. Responsible for migrating legacy TECS data into a “target” database
available for consumption by the ICM system provider. The Data Migration Team, in conjunction
with HSI, will identify all legacy records required for ingestion into the ICM system.
Integration. Responsible for coordinating integration among all the components of the ICE
TECS Modernization system including data migration, HSI requirements, internal and external
interfaces, and the ICM system. This team will serve as the release manager to ensure
infrastructure availability and will coordinate deployments to environments throughout the
system lifecycle.
Statement of Objectives
Version 1.0
Page: 6

•
•
Test. Oversees implementation of the Test and Evaluation Master Plan (TEMP), which is
provided as Exhibit G, and is responsible for overall integrated test planning and coordination.
Training and Communication. Responsible for developing and delivering the training strategy,
assisting in communications related to change management and leadership mobilization,
developing a training and education plan, and communicating with the user community. The
Offeror shall also provide some aspects of training for the ICM system (see Section 7.4).
4.2 HSI Investigative Case Management Ecosystem View
The HSI Investigative Case Management Ecosystem View diagram shown in Figure 1 illustrates a
reactive case initiated by an event and concluded upon reaching judicial process. This diagram shows the
following ICM processes:
•
•
•
•
•
•
•
•
•
Initiating an investigation beginning with an event or allegation
Evaluating the event or allegation as it relates to potential criminal or administrative violations
Documenting the initiation of the investigation by generating a case
Conducting investigative activity involving searching and retrieving information internal to the
ICM system that includes all types of subject records and other indices internal to ICE as well as
external or interfaced systems and information, including CBP and other federal, state and local
law enforcement partners
Documenting investigative findings as part of the case
Creating and documenting intelligence and other information related to the investigation
Interfacing and utilizing analytical tools to further develop intelligence and investigative
information
Creating subjects records and passing lookouts* to CBP via the CBP lookout service
Creating charging documents to facilitate prosecution in coordination with federal, state and local
prosecutors.
*A lookout is an ICM system subject record shared with CBP for enforcement action and/or to support
further investigations. Once shared, the lookout record becomes searchable and viewable by CBP
according to defined access control permissions.
Statement of Objectives
Version 1.0
Page: 7

Figure 1: HSI Investigative Case Management Ecosystem View
5. Mission Capabilities for the ICM System
The ICM system shall create, modify, close, query, view, print, and export ICE Investigative cases. The
ICM system shall capture, store, and manage the data and other information relevant to ICE criminal and
administrative investigations. The ICM system shall import legacy subject records and user data records
from the ICE/CBP TECS mainframe system after the data has been migrated to an Oracle Relational
Database Management System (RDBMS) by the ICE Data Migration Team.
Several high-level functional capability areas are described in this section to highlight some unique HSI
requirements for the ICM system but are not intended to represent all HSI mission requirements. The
Offeror shall meet the detailed requirements specified in Exhibit A.
Figure 2 is a high-level overview of HSI’s core ICM processes and their relationship to other components
of the ICE TECS Modernization system (e.g., the ICE Data Warehouse and the ICE interface hub). Also,
Figure 2 shows the types of requirements that pertain to all ICM processes in the (green) vertical layers.
More detailed HSI ICM processes, along with a mapping of HSI functional requirements to each process,
are provided in Exhibit B.
Statement of Objectives
Version 1.0
Page: 8

Figure 2: CORE HSI Investigative Case Management Processes
5.1 Case Creation and Management
The ICM system shall create new ICE investigative cases. An investigative case is a “container” for
numerous component documents/forms that support an investigation, such as the ROIs, internal
management documents, subject records, and electronic surveillance data (ELSURs). The case is
composed of metadata fields (such as program codes, case owner, supervisor name, etc.), a short
narrative, and a hyperlinked link list of all records attached to the case and its numerous component
documents.
The ICM system shall modify cases, close cases, and query/view/print/export cases. The ICM system
shall capture, store, and manage data and other information relevant to ICE criminal and administrative
investigations. The ICM system will not directly import legacy cases and component documents with the
exception of subject records and user data records. However, the ICM system shall query legacy cases
(which will be migrated to the ICE Data Warehouse). New cases created by the ICM system shall also be
exported to the ICE Data Warehouse. The ICM system user shall be able to submit a single query that will
return both legacy data and ICM system data and component documents in a consolidated result set.
5.2 Subject Record Management
The ICM system shall create new subject records, modify subject records, query/view subject records,
delete subject records, and print/export subject records. Subject record types shall include but should not
Statement of Objectives
Version 1.0
Page: 9

be limited to: Person, Business, Vessel, Vehicle, Aircraft, and Thing (a catchall type for other subject
types).
The ICM system shall manage subject records allowing for: (1) an “entity” concept that enables multiple
users to contribute to a communal set of identifying data about a subject (e.g., numerous users can add
dates of birth for a single individual documented within the system); and (2) and the ability for each user
to control his/her own data with individual access control rights. ICM system solutions that merely allow
for a communal single record with shared rights will not meet this need, nor will solutions that facilitate
the creation of multiple, duplicative records describing the same subject.
Due to the nature of their business, HSI agents collect most of the data elements on a subject of
investigation in a one-to-many fashion. There are few attributes about a subject that are captured as a
single instance value. The multiple values can be based on observations at various points in time, tips,
falsified documents, etc. Each of the multiple values is considered a valid attribute, not deactivated or
overwritten by more recently or more reliably obtained data. The ICM system shall make each value
editable and searchable, both individually as well as in any combination of the one-to-many attributes that
define the subject. For example, if a query on birthdate and social security number is run against all
person subjects of investigation, a subject who has two birthdates and three social security numbers will
be returned in the result set if there is a match with either one of the two birthdates and any one of his
three social security numbers. Figure 3 provides a high-level view of one-to-many relationships in HSI
subject records.
Figure 3: Example of One-to-Many Relationships in HSI Subject Records
5.3 Data Migration of Existing Legacy TECS Subject Records
Under a separate effort, the ICE TECS Modernization program will migrate HSI’s legacy data from the
TECS mainframe to an Oracle RDBMS (target database). The migrated data will contain all domains such
as cases, ROIs, other case reports, subject records, and user data. The Oracle RDBMS will preserve the
data cardinality and relationships among records.
The legacy cases and ROIs are considered “point-in-time” data and will not be required to be imported by
the ICM system. However, subject records are the cornerstone of HSI’s investigative process and shall be
imported by the ICM system. Subject record-related access control and document links (subject-tosubject, subject-to-ROI, subject-to-case) will be available in the Oracle RDBMS, and shall also be
imported and preserved in the ICM system with the subject record data.
Statement of Objectives
Version 1.0
Page: 10

User data and legacy access control data shall also be imported into the ICM system to associate record
ownership and continue to support access control. The user data provides attributes about a user’s
organization and role within HSI and will tie in with ICE’s single sign-on (SSO) mechanism.
Note that while other data domains (such as cases and ROIs) do not need to be imported by the ICM
system, this information will be transferred to the ICE Data Warehouse during initial data migration. The
ICM system shall search both the previous “point-in-time” data in the ICE Data Warehouse as well as
newly created and managed ICM system data (i.e., new cases and ROIs) in a federated manner without
requiring users to perform separate queries.
5.4 Reports of Investigation
The ROI has a unique workflow when compared to other case documents. The ICE agent who originated
the ROI must also be the final author. That is, if a supervisor makes changes to the narrative of a
submitted ROI, it is no longer considered a final draft for approval and would be routed back with the
tracked changes/comments to the originating author in draft status.
Once an ROI is approved, the ICM system shall convert it to an Adobe PDF document and save it as the
only version of the ROI. Earlier drafts of the ROI shall be eliminated. Once approved, no modifications to
the narrative can be made by the operational user. However, a defined small subset of administrative users
should have the ability to update or delete approved reports under limited circumstances.
The ROI differs from other documents in the system in that an ROI maintains both an “ROI author” and
the “ROI owner.” The ROI author can never change, even if the author is no longer a user provisioned in
the ICM system. The ROI owner can change as follows: the “ROI owner” is always the current case agent
for the case which contains the ROI. For example, if a user writes an ROI for his/her own case, but the
case is later transferred to a different user, the ROI author will not change, but the ROI owner will
become the new case agent. Likewise, if a user writes an ROI to another user's case, the ROI author and
the ROI owner will be two different users.
The ICM system shall generate final, approved versions of all ROIs in the same template format (i.e., a
standardized form with the same header, footer, and letterhead).
5.5 Notifications
The ICM system shall generate query and workflow-related notifications and send the notifications to
ICE/HSI users to support ICE/HSI business processes. Query notifications shall be role based and
adaptable to allow for notifications to occur or not occur based on defined circumstances. For example,
the ICM system shall issue a query notification through email to a record owner of any queries conducted
on his/her record, even if the record was not displayed because the querying user did not have access to
the record.
The ICM system shall allow certain ICE user groups, for example ICE's internal affairs unit known as the
Office of Professional Responsibility (OPR), to have special profiles that allow them to query records
without generating query notifications to the record owner. ICM system users shall be able to set rules
defining what does and does not trigger a query notification. Query and workflow notifications shall be
provided by email. The query notification shall include information about the person conducting the
query (both internal and external to ICE) and the path on which the record was viewed. If a record is
queried by another HSI user, the notification shall indicate the date, time and location of the query.
Additionally, the notification shall indicate the type of query and data the officer used to query the record.
For example, a record owner would receive a notification that "HSI Special Agent John Smith queried
your record on Jack Johnson from the San Antonio Texas field office by querying <last name>, <first
name> and <date of birth>".
Statement of Objectives
Version 1.0
Page: 11

5.6 Interfaces
To support HSI operations, the ICM system shall interoperate with specified internal ICE and DHS
systems and with specified systems external to DHS via data services provided by an ICE interface
hub. In addition, the ICM system shall interface directly with the ICE Data Warehouse. The ICM system
shall process transactions and updates that originate from external systems and shall share information
with external systems through data services or open APIs. Additional information on interfaces is
provided in the technical requirements section of this SOO.
5.7 Flexible Linking of Cases, Documents, and Subject Records
The ICM system shall link cases, documents and subject records to each other “vertically,”
“horizontally,” and in a “nested” fashion. Individual document-level (or field-level) access control shall
apply to linked records. The following examples describe each link category.
•
•
•
Vertically Linked: Subject records, for example, are “contained” within a larger case by virtue
of the fact that they have a many-to-one relationship with the case.
Horizontally Linked: Records of the same document type can be linked to one another. For
example, there can be “subject to subject” linking, where a Person subject record (PSR) is linked
to a Business subject record because the person works at the business. Users shall be able to link
these two subject record types in such a way that retrieving one of the records will cause the other
linked records to be displayed (many-to-many relationship) in a “link list” for both records.
Nested: An investigator may document an individual as a subject of his/her investigation in a
PSR. The same investigator may also document a vehicle in a vehicle subject record (VSR) that
will contain a series of fields to identify the owner of the vehicle. If during the course of
investigation s/he learns that the vehicle is in fact owned by the person, the user will be able to
“nest” the PSR “within” the VSR in such a way that the user would not need to perform dual
entry by typing the owner’s information in both the VSR’s “car owner” fields as well as the
creation of the VSR. The ICM system shall link the records together (many-to-many relationship)
such that (1) the user does not need to perform dual entry and (2) the “nested” record will appear
as such within the view of another record. From a technical perspective this is the same as
horizontal linking with the addition of an intuitive user interface component and the re-population
of data from one record type to another.
5.8 User Control of Access to Case-Related Information
The ICM system shall enable ICE/HSI users to control access of case-related information according to
core user roles including: Case Agent, Case Supervisor, ROI Narrative Author, ROI Narrative Author's
Supervisor, and other Supervisors. When a user searches for, or wishes to modify, records in the system,
access to the records shall be based on the role of the user and the access control level set by the record
owner(s).
The ICM system shall enable users to delegate responsibilities to other users. As an example, agents shall
be able to open cases on behalf of other agents, and supervisors shall be able to delegate approval
authority to other agents or supervisors when they are out of the office. Users shall be able to transfer
documents to each other with supervisor approval. Also, multiple agents shall be able to contribute to a
single work process; for example, several agents can write ROIs against a single user’s case.
One unique HSI workflow requirement is the interaction between user roles and workflow states. For
example, if an agent submits a report to his/her supervisor, the record shall be visible only to that agent
and to the supervisor while in draft status. However, once the document is approved it shall become
available to the larger HSI user community (within the confines of access control rules, which are
specified by the document owner).
Statement of Objectives
Version 1.0
Page: 12

Exhibit F is a set of Responsible, Accountable, Consulted, Informed (RACI) charts that define ICE/HSI
user roles in terms of who is responsible, accountable, consulted, and informed with regard to ICM
system actions that may be taken by those users. The Offeror shall implement the detailed user role
requirements described in these charts and in the requirements specified in Exhibit A.
5.9 Transfers of Users, Cases, and Subject Records
The ICM system shall handle transfers of HSI users, cases, and subject records according to the following
business rules.
User Transfers: The ICM system shall not allow the reassignment of a user to a different office if that
user’s documents have not first been transferred to a different owner. The receiving owner must be
assigned to the office associated with the documents to be transferred. For example, before agent Doe is
transferred out of the New York office, his documents must first be transferred to another New York
agent.
Case Transfers: The ICM system shall transfer (1) individual documents, including cases, subjects, ROIs
and other case documents, to another user and (2) select several documents at once for transfer. If a case
is transferred, the ICM system shall automatically transfer all linked documents. Note: An ROI always
retains its original author.
Subject Record Transfers: The ICM system shall transfer unlinked subject records as a separate process
from case transfer. The ICM system shall transfer subject records individually or several at once.
The ICM system shall check to make sure the receiving user is authorized to view all documents
transferred to him/her. If the recipient does not have authorization for any document, the ICM system
shall disallow the transfer and prompt the initiator to manually add the recipient to the list of authorized
viewers for the document. This ensures that documents are not inadvertently transferred to unauthorized
users.
Document transfers must be approved by the user’s supervisor. As with all workflows in the system, the
supervisor can both initiate a workflow and also approve the same workflow. (Thus, a supervisor can
approve his/her own work.)
5.10 Searching Structured and Unstructured Data Across Document Types
The ICM system shall search both structured and unstructured data across multiple document types and
possibly multiple systems internal and external to ICE and DHS. Structured data searches ensure
consistency of search results within a specific search type, while unstructured or keyword searches
provide the capability to search across structured data and narrative data (unstructured documents and free
text contained within the narrative portion of a document). The ICM system shall include subject record
search forms.
The following is an example of this essential capability with regard to structured data: addresses (and
their constituent groups of fields) exist in multiple documents throughout the system, such as the person
subject record, financial data (interface), CBP crossing data (interface), and other HSI and CBP subject
record types. The user shall be able to conduct a consolidated address search that will match on all
addresses regardless of the record type (internal or external to ICE/HSI) that contains them.
An ICM system user shall be able to search on the string “John Doe.” This search shall return results
where “John Doe” exists as a name on a form (structured) and/or the words “John Doe” appear in a
narrative (unstructured). Users shall have the separate capability to search for “John Doe” as only a
structured name within a specific record type.
Statement of Objectives
Version 1.0
Page: 13

5.11 Agent Work Hours
The ICM system shall enable HSI users to accurately document their hours worked each month, to
include regular work hours, unscheduled overtime, undercover work hours, etc. The ICM system users
shall be able to attribute the hours they enter to cases. The ICM system shall enable the user-entered hours
to be accumulated and reported. For example, the ICM system shall report on the number of investigative
hours spent on all narcotics cases involving methamphetamine. Also, the ICM system shall report
granular elements such as hours worked by agent, by program code, etc.
6. Technical Capabilities for the ICM System
The Offeror shall meet the detailed requirements specified in Exhibit A. The following high-level
technical capability areas highlight some important ICE/HSI requirements for the ICM system but are not
intended to represent all technical requirements. The detailed requirements specified in Exhibit A take
precedence if any deviations occur between requirements associated with the capability areas described in
this section and the detailed requirements in Exhibit A.
6.1 Hosting Environments
Through a DHS private cloud environment, the ICE TECS Modernization program will have access to a
pool of servers providing Virtual Machines (VMs) that can be used for the systems development lifecycle processes. The DHS cloud provides Development and Test as a Service (DTaaS) and Infrastructure
as a Service (IaaS). The hosted environments include systems management, monitoring, security auditing,
and 24/7 operations support as is provided for all other servers within the DHS enterprise data center.
Available operating systems are RedHat Enterprise Linux 5 and 6, Windows Server 2008 R2, and
Windows 7.
The Government will provide the infrastructure to all of the development teams supporting the ICE TECS
Modernization program. Developer VMs can be ordered in several sizes suitable for uses that range from
web servers to large database server/hosts, each with a choice of operating systems. The Government has
identified requirements for at least nine (9) types of system environments to support the ICE TECS
Modernization program as shown in Table 1.
Table 1. ICE TECS Modernization Program Hosting Environments
Environment
Development (DEV)
Development Integration
(INT)
System Test (TST)
Performance Test (PERF)
User Acceptance Test (UAT)
Training (TRN)
Staging (STG)
Production (PROD)
Disaster Recovery (DR)
Statement of Objectives
Purpose
Development environment (separate environments for
major components of the ICE TECS Modernization
system)
Integration and test environment
Formal system testing to validate integration and
interoperability among all components
Performance testing (load, capacity, response time)
User acceptance testing prior to deployment at IOC
User training and related documentation (ongoing)
Validation of deployment configuration prior to
transition to production
Production environment
Disaster recovery environment
Version 1.0
Page: 14

The Offeror has the option to propose alternatives to the VM environments above to meet their hardware,
software and overall performance requirements. However, given the compressed schedule, the Offeror
should provide details on any proposed alternative implementation approach along with an associated risk
mitigation plan and a detailed cost estimate (See RFP, Attachment 6-CLIN Structure, CLIN XX07).
6.2 Key Performance Parameters and Maintainability
Key performance parameters (KPPs) are specified for the ICE TECS Modernization system in the ICE
TECS Modernization System Operational Requirements Document (ORD), which is provided as Exhibit
E to the RFP. These KPPs are shown in Table 2. As the overall ICE TECS Modernization system
includes several components, the Offeror shall meet the performance requirements relevant to their
solution and its key role in the overall ICE TECS Modernization system.
In addition to the KPPs in Table 2, there are other performance requirements (e.g., related to
maintainability) in the detailed requirements in Exhibit A. The availability KPP in Table 2 shall drive the
ICM system maintainability requirements in terms of mean time to restore service (average time to restore
service after a failure), mean downtime (time that the ICM system is not operational due to service
incident or preventive maintenance including logistic and administrative delays), and planned downtime
(time that the ICM system is not operational due to corrective and preventive maintenance including
logistic and administrative delay time).
Table 2. KPPs for the ICE TECS Modernization System
No. KPP
1
Response Time:
Transaction response time
refers to the time required
for completion of an
individual transaction.
Specifically, the time it
takes from a workstation
request to a workstation
response, which is tested at
the end user device level.
Test time begins when the
user hits enter after filling
out the appropriate
transaction criteria and ends
when the intent of the
transaction is accomplished,
for example when search
results appear on the results
page.
Threshold
Objective
Comments
The system shall
provide operationally
acceptable
transaction response
time* for individual
transactions across
the system, not to
exceed 5 seconds
95% of the time.
The system shall
provide a transaction
response time* for
individual
transactions across
the system, not to
exceed 3 seconds
99% of the time.
*Response time
excludes
transaction
processing time on
systems external to
the investigative
case management
application.
Response time for search
includes responses from all
data sources queried.
Statement of Objectives
(For example,
processing within
the ICM application
must not add more
than 5 seconds to
the time required
for an external
database to process
a request with
regard to Threshold
or 3 seconds with
regard to
Objective.)
Response time is
calculated only for
devices directly
connected to an
Version 1.0
Page: 15

No. KPP
Threshold
Objective
Comments
ICE network and
does not include
remote devices (i.e.,
connected through
VPN, mobile
device running over
wireless network,
etc.).
Concurrent Users:
2
The system shall be able to
handle a high level of users,
measured by the number of
concurrent users accessing
the system at the same time.
3
Availability:
No less than 6,000
users accessing the
system at the same
time with system
capability allowing
all users to conduct
business transactions
concurrently within
the application.
No less than 10,000
users accessing the
system at the same
time with system
capability allowing
all users to conduct
business transactions
concurrently within
the application.
Approximately
90% of system
transactions are
database reads.
Database updates
consists of the
remaining 10%.
Ao > 99.07%
Ao > 99.97%
Required level of
monthly
Operational
Availability for the
ICM system
components.
The ICM system shall
achieve the required level
of Operational Availability
(Ao).
6.3 Measures of Effectiveness
The following measures of effectiveness (MOEs) describe high-level capabilities pertaining to ICM
system capability objectives the Offeror’s proposed solution shall meet:
•
•
•
•
•
•
•
•
•
Ability for all users with appropriate access to view cases and all associated documents, subject
records, and links within five seconds of being created when they are accessing the system from a
device directly connected to an ICE network
Ability for users to create a lookout record and have that record available for posting to CBP
TECS Portal within five seconds (via an ICE-developed data service)
Ability for users to perform all work flow related to cases, case documents, and subject records
(i.e., opening/creating, approving, modifying, deleting)
Ability for users to link cases to case documents and subject records/lookouts
Ability for users to link subject records/lookouts to case documents
Ability of the ICM system to receive and present search responses from all sources with which
the system interfaces within five seconds of the source data being made available to the ICM
system
Ability of the ICM system to generate audit trails to facilitate reconstruction of events on demand
Reduced data entry time via elimination of duplicative requests for input of data from users
Ability of the ICM system to interface with internal ICE/DHS systems and external systems as
described in other sections of this SOO.
Statement of Objectives
Version 1.0
Page: 16

6.4 User Provisioning
New agents will need to be provisioned to the ICE Active Directory (AD) prior to being provisioned in
the ICM system. This process is outside the scope of the ICM system user provisioning process. Once
users are added to ICE AD, the process to provision a user to the ICM system can be initiated by an HSI
System Control Officer (SCO) according to the three-step process shown in Figure 4. The process for
updating user profiles follows these same steps. The steps are explained in more detail below.
Figure 4. HSI User Provisioning for the ICM System
Step 1: The SCO will create a user profile in the ICM system as follows:
•
•
•
•
•
The SCO will enter user-name, middle-name, last name in a screen in the ICM system application
The ICM system application will query ICE AD to retrieve user(s) matching this query
The SCO will browse the list (if more than one is returned) and manually make a determination
of which one of the users is most likely the individual he/she is intending to provision in the ICM
system
The SCO will then select that user from the list
This completes the user-create process (some information from AD will be pre-populated in the
screen).
Step 2: The SCO will then: a) define role(s) for this agent and b) assign an office code to this agent (this
office code is based on an existing legacy office hierarchy).
Step 3: The SCO will then a) assign a supervisor to this user (filtered list of users based on the office
selected) and b) assign a SCO user to this agent.
The ICM system shall develop a static office hierarchy of its own and host it in the ICM system database;
therefore, a user’s office information will not be retrieved from the ICE AD. Users will need to selfregister upon initial logon to the ICM system. The ICM system shall present these users with a screen to
update their personal information including their ICE email addresses.
The SSO process will use the ICE AD for initial user authentication. The ICM system shall then validate
the user to the ICM system if that user has been provisioned in the ICM system user. Though all the ICM
system users have an active ICE AD, not all ICE AD users have access to the ICM system. Merely having
an active ICE AD, does not in and of itself mean a user can perform functions in the ICM system.
Statement of Objectives
Version 1.0
Page: 17

6.5 Single Sign On
The ICM system shall implement standards-based mechanisms, such as Security Assertion Markup
Language (SAML 2.0), to achieve SSO within the DHS and ICE infrastructure. Authentication will be
externalized to the ICM system. Oracle Access Manager is currently used as a proxy to AppAuth for
Active Directory authentication of individual users. The ICM system shall implement industry standard
Web Access Management (WAM) methods to enable SSO for application components of the ICM
system.
6.6 Interfaces
The ICM system shall query and search specified data sources that are internal to ICE or DHS and
external to DHS. Information shall be requested from interface partners by calling Simple Object Access
Protocol (SOAP)-based web services exposed via the ICE Interface Hub which will be implemented by
the ICE Interfaces Team. In addition, the ICM system shall interface directly with the ICE Data
Warehouse. The ICM system shall authenticate and authorize individual users accessing interface
services, and shall include the user’s authenticated identity in each call for auditing purposes. The ICM
system shall authenticate to the ICE Interface Hub using digital certificates and shall use secure socket
layer (SSL) encrypted channels when transmitting or retrieving sensitive information via an interface. The
ICM system shall process inbound interface information such as training and certification updates and
asynchronous request notifications. Table 3 summarizes the interface operations that shall be supported
by the ICM system.
Table 3. ICE TECS Modernization System Interfaces
Interface Title
Operation Description
Direction
End Point
AsyncResultNotification
NCIC/NLETS Result
Notifications
Inbound (from the
ICE Interface Hub)
ICM system
VUTrainingUpdate
User Profile Updates
Inbound (Update)
(from the ICE
Interface Hub, data
will need to be
persisted in ICM)
ICM system
Outbound
(Query/Search)
ICE Interface Hub
(responds with detail
query response,
correlation ID in the
event of asynchronous
response, summary hit
list, or exception
message)
(Training Certifications)
SearchPersonSubject
Statement of Objectives
ICM system provides
various person attributes as
query parameters and/or
ranges as well as valid
query targets. ICM may
also provide a correlation
ID for a response received
from
AsyncResultNotification.
Version 1.0
Page: 18

Interface Title
Operation Description
Direction
End Point
SearchVehicleSubject
ICM system provides
various vehicle attributes as
query parameters and/or
ranges as well as valid
query targets. ICM may
also provide a correlation
ID for a response received
from
AsyncResultNotification.
Outbound
(Query/Search)
ICE Interface Hub
(responds with detail
query response,
correlation ID in the
event of async
response, summary hit
list, or exception
message)
SearchAircraftSubject
ICM system provides
various aircraft attributes as
query parameters and/or
ranges as well as valid
query targets. ICM may
also provide a correlation
ID for a response received
from
AsyncResultNotification.
Outbound
(Query/Search)
ICE Interface Hub
(responds with detail
query response,
correlation ID in the
event of async
response, summary hit
list, or exception
message)
SearchVesselSubject
ICM system provides
various vessel attributes as
query parameters and/or
ranges as well as valid
query targets. ICM may
also provide a correlation
ID for a response received
from
AsyncResultNotification.
Outbound
(Query/Search)
ICE Interface Hub
(responds with detail
query response,
correlation ID in the
event of async
response, summary hit
list, or exception
message)
SearchBusinessSubject
ICM system provides
various business attributes
as query parameters and/or
ranges as well as valid
query targets. ICM may
also provide a correlation
ID for a response received
from
AsyncResultNotification.
Outbound
(Query/Search)
ICE Interface Hub
(responds with detail
query response,
correlation ID in the
event of async
response, summary hit
list, or exception
message)
SearchThingSubject
ICM system provides
various thing attributes as
query parameters and/or
ranges as well as valid
query targets. ICM may
also provide a correlation
ID for a response received
from
AsyncResultNotification.
Outbound
(Query/Search)
ICE Interface Hub
(responds with detail
query response,
correlation ID in the
event of async
response, summary hit
list, or exception
message)
Statement of Objectives
Version 1.0
Page: 19

Interface Title
Operation Description
Direction
End Point
SearchSubscriber
ICM system provides
various telephone
subscriber attributes as well
as query targets
(Falcon/TLS is expected to
be only valid target for
IOC)
Outbound
(Query/Search)
ICE Interface Hub
(responds with detail
query response,
summary hit list, or
exception message).
SearchPenRegister
ICM system provides
telephone digit information
as well as query targets
(Falcon/TLS is expected to
be only valid target for
IOC)
Outbound
(Query/Search)
ICE Interface Hub
(responds with detail
query response
[including related case
numbers], summary
hit list, or exception
message).
GetCaseStatistics
ICM system provides case
and 151/incident
information as parameters
Outbound
(Query/Search)
ICE Interface Hub
(responds with
updated incident
information,
preliminary case
statistics, and final
case statistics
retrieved from CBP
SEACATS or
associated CBP data
stores)
SearchEvent
ICM system provides event
centric query parameters,
such as flight parameters,
border crossing, arrest,
seizures, financial
transactions, financial
declarations (CMIR),
shipments (cargo).
Outbound
(Query/Search)
ICE Interface Hub
(responds with
matching event
information as linked
subject information as
available from the
queried target.
Subsequent queries
may be required to
retrieve detailed
subject information)
CreateSubjectLookout
ICM system provides all
required subject attribute
information (for all
supported subject types),
lookout status, as well as
query and lookout
notification conditions.
Outbound
(Update)
ICE Interface Hub
(responds with CBP
TECS Subject ID,
Date/Time Subject
Lookout update
confirmed [if placed
on lookout])
Statement of Objectives
Version 1.0
Page: 20

Interface Title
Operation Description
Direction
End Point
UpdateSubjectLookout
ICM system provides CBP
TECS Subject Identifier
and Lookout Status
Updates (ON/OFF
Lookout, Lookout Level)
and lookout notification
conditions. This operation
is used to place existing
subjects on lookout as well
as remove them from
lookout.
Outbound
(Update)
ICE Interface Hub
(responds with CBP
TECS Subject ID,
Date/Time Subject
Lookout update
confirmed [if placed
on lookout])
ReceiveEventNotification
Allows ICM to be made
aware of subscribed law
enforcement events and
information related to cases
and/or investigative
subjects, such as seizures,
arrests, border crossings,
and other information.
Inbound (from the
ICE Interface Hub)
ICM system
6.7 Data Migration
Table 4 provides a high-level description of the ICE/HSI user data and subject domains that will be
migrated from the legacy TECS system to a target database and, from there, imported into the ICM
system. In addition to the database tables shown in Table 4, there are 11 global reference tables that are
shared across domains and there are other reference tables that support ICM system functionality (e.g.,
cases and documents) even though the associated legacy TECS data is not being migrated into the ICM
system. All these reference tables shall be migrated from the legacy TECS system and imported into the
ICM system. The data model for the target database is provided as Exhibit C to this RFP.
Table 4. Legacy TECS Data to be Migrated to the ICM System
Data
Domain/
Document
Description
No. of Tables
No. of
Assoc. Ref
Tables
Record
Count
in Base
Table
7 tables: 1 base
plus 6 child
38 tables
35K
User Profile
User attributes that define
access control, document
creation, workflow,
notifications, etc.
Access
Control
Read, write, and approval
restrictions that are defined on
each document.
3 tables: 1 base
plus 2 child
7 tables
4.7M
Statement of Objectives
Version 1.0
Page: 21

Data
Domain/
Document
Description
No. of Tables
No. of
Assoc. Ref
Tables
Record
Count
in Base
Table
Person
Subject
Tables for a Person Subject
record (dependent on
supertype).
28 tables: 1
base plus 27
child
26 tables
3.4M
Vehicle
Subject
Tables for a Vehicle Subject
record (dependent on
supertype).
8 tables: 1 base
plus 7 child
3 tables
565K
Business
Subject
Tables for a Business Subject
record (dependent on
supertype).
16 tables: 1
base plus 15
child
4 tables
607K
Aircraft
Subject
Tables for an Aircraft Subject
record (dependent on
supertype).
10 tables: 1
base plus 9
child
8 tables
24K
Vessel
Subject
Tables for a Vessel Subject
record (dependent on
supertype).
12 tables: 1
base plus 11
child
1 table
51K
Thing
Subject
Tables for a Thing Subject
record (dependent on
supertype).
13 tables: 1
base plus 12
child
4 tables
14K
SubjectCase Links
Table for associating a Subject
with a Case.
1 table
4.8M
SubjectROI Links
Table for associating a Subject
with an ROI.
1 table
6.7M
SubjectSubject
Links
Table for associating a Subject
with another Subject.
1 table
7.6M
Two general kinds of permission are used in the legacy TECS system: (1) read access to records and (2)
access to transactions that may alter the records.
Each subject record in the legacy TECS system may be assigned one of three access levels:
Level 1. All users have access
Level 3. Users belonging to one or more specified groups have access
Level 4. Access is limited to specified users.
Access level 2, which limits access to a certain agency, is available but not used for subject records.
Transactions can be assigned to a user via a profile code or through direct association. Typically, a user
will be assigned a profile code that gives the user membership in a set of groups or permission to execute
a set of transactions. The direct assignment of a group or transaction is unusual, can be performed only by
privileged users, and is likely to be temporary.
Statement of Objectives
Version 1.0
Page: 22

6.8 ICE Data Warehouse
The ICM system shall use SQL or a web service to extract data for all HSI domains from the ICE Data
Warehouse. The ICM system shall receive multiple queries per day to meet near real-time reporting
requirements. In order to minimize impact to transactional processing in the ICM system, the ICM system
shall identify database changes since the last extraction of data to refresh the ICE Data Warehouse. For
example, the ICM system might use separate views, tables, or flat files holding only the information
added or updated since the last refresh time. New or updated records shall be labeled by the ICM system
via created/updated time stamps on all records.
The ICM system shall access the ICE Data Warehouse to conduct searches for legacy data not imported
into the ICM system. The ICE Data Warehouse will retrieve legacy data (e.g., cases and ROIs) as well as
new data created by the ICM system, and return results back in an XML file. The ICE Data Warehouse
will have mechanisms to enforce access control and will only return results to which requesting users
have access. The ICM system shall render the results from the ICE Data Warehouse in MS-Word, PDF,
or similar formats.
6.9 Security and Privacy
The system shall be compliant with all relevant security controls outlined in the Federal Information
Processing Standard (FIPS) and the Federal Information Security Management Act (FISMA) to include,
but not limited to, the ability of the federal government to perform a security certification and
accreditation process to obtain an authorization to operate that will be signed by the federal principal
without delay to system deployment. Specific security and privacy requirements for the ICM system are
specified in the detailed ICM system requirements provided as Exhibit A to the RFP.
DHS/ICE has determined that all Offerors/subcontractor(s) performing work under the ICE TECS
Modernization contract will have access to sensitive but unclassified (SBU) DHS and ICE information,
which requires DHS Suitability Clearance 5C (Moderate Risk) position of public trust adjudication.
6.10 Licensing and Data
Any software proposed by the Offeror for use to develop ICE’s ICM system shall be approved by the
Government before any purchase or use. The Licensee of any such software product shall be ICE.
License agreements shall be provided to ICE for final review to ensure the terms of the license agreement
are consistent with federal law and will meet ICE’s needs. The Offeror shall ensure that it has complied
with Section H requirements pertaining to licensing before it will be approved for use in development of
ICM.
Any data input by ICE, or its support contractors, into the ICM system shall remain ICE property and ICE
retains ownership of said data. If the ICM system is based upon a COTS solution, then ICE anticipates
that the system will be modified to address ICE’s ICM system requirements. Any software modifications
made to the system under this contract shall be provided to the government with unlimited rights.
Unlimited rights means that the Government has unlimited rights to use, disclose, reproduce, prepare
derivative works, distribute copies to the public, and perform publicly and display publicly, in any manner
and for any purpose, and to have or permit others to do so as defined in FAR 27.401. ICE shall also
obtain unlimited rights in any other data first produced in performance of this contract, form fit, and
function data and all other data delivered under the contract other than restricted rights in commercial
computer software. If the ICE system is based upon a Government Off the Shelf solution, ICE also
anticipates that the system will need to be modified to address ICE’s ICM system requirements. ICE
Statement of Objectives
Version 1.0
Page: 23

shall have unlimited rights to all software modifications as defined above and shall have the same rights
in the GOTS solution as the Government previously acquired when the GOTS software was developed.
ICE shall retain ownership of any training plans and manuals, all data input in the system, and all outputs
of the system including all investigative reports created by a User of the system. Outputs of the system
include both the data and formatting of the outputs. The Offeror shall not attach any unauthorized or
restricted markings on this material. This material shall be delivered IAW FAR 52.227-17.
7. Implementation and Management
The overall ICE TECS Modernization program will follow structured DHS-approved lifecycle
implementation processes as outlined in the ICE System Lifecycle Management (SLM) Handbook and
will refer to the ICE Technical Reference Model (TRM) for commercial products already approved by
ICE. The ICE TRM is provided as Exhibit I to the RFP. The Offeror shall conduct an implementation
strategy, in collaboration with the Government that aligns with the ICE SLM Handbook and industry best
practices for managing programs and projects. During ICM system implementation and management, the
Offeror shall collaborate closely with the Government and other developers on the ICE TECS
Modernization program. In particular, the Offeror shall provide the Government with complete visibility
and transparency into all phases of their implementation and management work on the ICE TECS
Modernization program, including working co-located with the Government, conducting daily
collaboration with Government counterparts, both technical and functional, sharing of status on a realtime basis via joint contractor/Government teams. Such collaboration will enable the Government to
determine acceptance (or not) of the technology and functionality being development efficiently and
effectively.
7.1 Development, Test, and Deployment Approach
DHS/ICE will provide the hosting environments described in Table 1 (Section 6.1) to support
development, test, and deployment activities for all ICE TECS Modernization system components,
including the ICM system unless otherwise proposed by the Offeror and approved by the Government.
The Offeror shall use these hosting environments for development, configuration, integration, and testing
of their solution. (Note that Section 6.1 in this SOO allows the Offeror to propose alternatives to the
DHS/ICE hosting environments.) The Offeror shall be responsible for all demonstration testing to verify
that its’ system is working properly prior to submitting it for integration. The Offeror shall participate in
all levels of integration and testing as the overall ICE TECS Modernization system progresses to IOC.
Specifically, the Offeror shall assist in analyzing problems discovered during all levels of integration and
testing. The Offeror shall correct errors and shortfalls (example of shortfall is not meeting performance
requirements) in the ICM system during all levels of integration and testing.
Software code changes applied to the Offeror’s system to support the ICM system requirements shall be
developed to be compatible with, and shall not prevent the ability to apply, future software maintenance
upgrades to the Offeror’s product that are made generally available. In general, the Government would
prefer that functional extensions or enhancements and error corrections developed for the ICM system
during all development, test, and maintenance activities be incorporated into the code base for the ICM
system so that future releases will include these changes. Code developed by the Offeror for ICE shall
require approval by the Government to be incorporated into the ICM system code base. The Government
shall have unlimited rights to any code developed by the Offeror specifically for ICE and not incorporated
into the ICM system code base.
Statement of Objectives
Version 1.0
Page: 24

7.2 Service Desk Support.
The Offeror shall support the ICE TECS Modernization system service desk as described below.
Tier 1. The Government will provide Service Desk Tier 1 support for the overall ICE TECS
Modernization system. The Offeror shall be responsible for Tier 2 and 3 system support for the ICM
system and for assisting with the overall problem resolution of the ICE TECS Modernization system.
Tier 2. All problems that cannot be resolved at the Tier 1 support level will be automatically turned over
to Tier 2 System Maintenance and Support to be handled as follows:
•
•
•
•
The status of the problem ticket shall be reported using an ICE approved tracking tool
Typical Tier 2 activities include patching systems, running scripts, and applying minor fixes
A feedback loop will be developed such that systemic issues identified during Tier 2 and Tier 3
escalation procedures will be routinely evaluated and reviewed with the appropriate project
manager to assess the need for a System Change Request (SCR) for incorporation into a future
release
If Tier 2 System Maintenance Support cannot resolve the assigned ticket or perform the required
tasks, then the ticket shall be referred to the Tier 3 System Maintenance and Support.
Tier 3. Software, performance, and implementation failures will be identified and evaluated and the level
of effort associated with requests for system modification will be estimated. Corrective work includes
generating SCRs that reflect the need to correct a component, re-integrate components to develop a
revised version of the overall system or revised version of a major component in the system, and perform
all levels of test on the revised version. Or, SCRs may indicate the need to change requirements or
technical specifications. Problems addressed at the Tier 3 level will likely require updating the Systems
Engineering Lifecycle (SELC) documentation as necessary. Tier 3 service desk support activities should
be handled as follows:
•
•
•
All maintenance activities that reach this level will have an SCR opened and be reported using the
ICE approved tracking tool
SCRs will be prioritized and approved in writing by authorized Government personnel and
entered into the ICE approved management tracking tool
Prior to commencing a system modification, ICE TECS Modernization system service desk
contractors and the OCIO IT project manager will determine the degree of the modification as
minor, moderate, or major and ICE approved processes for SCRs will be followed.
Tier 2 and Tier 3 Support standard hours of operation will be Monday through Friday 8:00 am and 8:00
pm Eastern Standard Time (EST), excluding Government holidays as designated by the United States
Office of Personnel Management (OPM). Table 5 summarizes Tier 2 and 3 performance requirements.
Statement of Objectives
Version 1.0
Page: 25

Table 5. Tier 2 and 3 Performance Requirements
Tasks
Tier 2 and Tier 3
Software Support
Service
Level
No more than 1
hour
Metric
Response time for Tier 2
and Tier 3 tickets during
standard support hours
How it will be
Measured
Time the ticket is assigned to
Tier 2 or Tier 3 until the time
the ticket is picked up for
action.
Tier 2 and Tier 3
Software Support
Resolution time of Tier 2 and 5 business calendar Time the ticket is placed in the
Tier 3 tickets
days
Tier 2 or Tier 3 queue for
action to the time it appears as
closed or deferred as a future
candidate for release.
Tier 2 and Tier 3
Software Support
Response time for emergency
tickets after hours
No more than 1
hour
Time the ticket is assigned as
an emergency until the time
the ticket is picked up for
action.
7.3 Maintenance Support
The Offeror shall provide their approach for maintenance of the ICM system solution for maintenance
periods that will be executed in 12-month (or remainder thereof) options for the remaining period of
performance (i.e., the balance of 48 months remaining after IOC).
This approach would include the Offeror’s basic approach to ICM system bug fixes/patches, routine
maintenance and upkeep of the ICM system solution, licenses and upgrades on the Offeror supplied
products associated with the ICM solution, and upgrade frequency for the installed ICM system solution.
7.4 Training Strategy
The Offeror shall describe all existing training plans and materials, user guides, operations manuals, and
maintenance manuals for their ICM system solution and shall provide these training-related items to the
Government. The Offeror shall provide subject matter expertise regarding the proposed solution, its
function, and corresponding training/user readiness lessons learned to support the Government in
developing the training program for the ICM system.
7.5 Systems Engineering Lifecycle Documentation
The ICE TECS Modernization Program will follow a COTS integration implementation pattern for the
ICE SELC Tailoring Plan provided as Exhibit D to the RFP. The Offeror shall produce the Work
Products and Deliverables described in Exhibit H to the RFP.
The Offeror shall deliver draft versions, revised versions, and final versions of required system
documents. The Offeror shall provide deliverables electronically, virus free and in the acceptable
electronic format mutually agreed to by the Government and Offeror.
7.6 Project Management
The Offeror shall collaborate with the Government and other contractors on all aspects of the ICE TECS
Modernization program to help achieve all objectives and requirements outlined or identified in this SOO
Statement of Objectives
Version 1.0
Page: 26

and other components of the RFP. The Offeror shall manage the ICM system implementation project
using industry best practices including:
•
•
•
•
•
•
Status Reporting. Weekly reports of status related to development, testing, staffing, issues, and
risks including date of completion during the IOC timeframe.
Communication. Due to the interrelationship of the various development, testing, training and
deployment activities, the Offeror’s project management activities shall include plans to build
relationships among all organizations involved in the ICE TECS Modernization program.
Risk Management. All systems development projects have inherent risks. Given the visibility of
this project, the Offeror will be incorporated into the Program’s risk management process,
logging all risks and mitigation strategies into a centralized Risk Register and meeting weekly to
discuss them to determine if they should become elevated risks. The ICE TECS Modernization
program will maintain oversight of all program risks via a risk review board chaired by the
Government program manager.
Configuration Management. The Offeror shall be responsible for the configuration management
activities associated with all aspects of implementing the ICM system, from initial installation
through final Government acceptance and during all levels of system integration and test.
Quality Assurance. The Offeror shall provide a Quality Assurance Surveillance Plan (QASP)
that outlines how the quality of the work associated with implementing the ICM system will be
assured.
IPT Support. The Offeror shall provide information (e.g. status reports) and attend weekly
reoccurring IPT meetings as described in Section 4.1.
7.7 Key Personnel
The Government requests a commitment letter for the following personnel to support the Offeror’s
performance on the ICE TECS Modernization program during the IOC timeframe. All key personnel shall
be intimately familiar with the specific ICM product proposed by the Offeror and shall have been
involved in key leadership roles during previous installations, configurations, and extensions to meet
customer requirements.
Project Manager
The Offeror’s Project Manager shall have relevant experience in managing the implementation of large
complex programs that involve working with other contractors to produce the overall system required by
the Government. The Project Manager shall work with the Government Program Manager, the
Government Contracting Officer, and other Government and contractor personnel to ensure that the
technical solutions and schedules are implemented according to the agreed upon schedule. The Project
Manager shall ensure the Offeror’s staff works with the Government and other contractors on the ICE
TECS Modernization program to perform horizontal integration planning and all phases of
implementation, test, and deployment.
Principal Systems Architect
The Offeror’s Principal Systems Architect shall have relevant experience in analyzing all requirements
pertaining to complex computer systems and developing architectures to guide the design of the system.
Such architectures should include software, hardware, databases, communications, and security and
privacy mechanisms to satisfy the total set of functional and technical requirements and to be scalable and
extensible to accommodate future requirements for the system. The Principal Systems Architect shall be
knowledgeable about, and experienced in developing, open system architectures, applying industry
architecture-related standards, and using reference models to further describe the architecture.
Statement of Objectives
Version 1.0
Page: 27

Principal Systems Engineer
The Offeror’s Principal Systems Engineer shall have relevant experience in all aspects of planning,
analysis, design, and development of complex computer systems. The Principal Systems Engineer shall
be knowledgeable about, and experienced in, the analysis of business/mission, technical, performance,
security and privacy requirements; system and component implementation methodologies and tools; data
modeling and data processing; integration; cross-system interoperability; and all aspects of testing large
complex systems that comprise components from multiple vendors and developers.
Principal Software Development Manager
The Offeror’s Principal Software Development Manager shall have relevant experience in all aspects of
system and software requirements analysis, system and software design to meet functional and nonfunctional requirements (including performance, scalability, extensibility, security, privacy), software
development, interface development, component integration and testing, subsystem integration and
testing, cross-system integration and testing, data modeling and database design, and software quality
assurance. The Principal Software Development Manager should be familiar with detailed aspects of
setting up and managing hosting environments for all phases of development and testing, and production.
8. Applicable Documentation
The Offeror shall comply with the Exhibits to this RFP (which provide more details on requirements and
implementation processes) and the latest versions of all technology standards and architecture policies,
processes, and procedures applicable to the overall ICE TECS Modernization program. These
publications include, but are not limited to, the following:
Exhibits Referenced in the SOO
•
Exhibit A: ICE/HSI Investigative Case Management System Requirements (Law Enforcement
Sensitive)
•
Exhibit B: ICE/HSI Business Process Deep Dive Diagrams (Law Enforcement Sensitive)
•
Exhibit C: Target Data Model for Data Migration (Law Enforcement Sensitive)
•
Exhibit D: ICE TECS Modernization SELC Tailoring Plan
•
Exhibit E: ICE TECS Modernization ORD
•
Exhibit F: ICE/HSI RACI Charts (Law Enforcement Sensitive)
•
Exhibit G: ICE TECS Modernization TEMP
•
Exhibit H: ICM System Table of Work Products and Deliverables
•
Exhibit I: ICE TRM
Other References Relevant to the SOO
•
DHS 4300A Sensitive Systems Policy Directive, Version 8.0, Dated March 14, 2011
http://www.dhs.gov/xlibrary/assets/foia/mgmt_directive_4300a_policy_v8.pdf
•
DHS MD 4010.2 (DRAFT), Section 508 Program Management Office & Electronic and
Information Technology Accessibility, Issued 10/26/2005,
http://www.dhs.gov/xlibrary/assets/foia/mgmt_directive_40102_section_508_program_managem
ent_office_and_information_technology_accessibility.pdf
Statement of Objectives
Version 1.0
Page: 28

•
Final FAR Rule for Implementing Section 508 of the Rehab Act Electronic and Information
Technology Accessibility for Persons with Disabilities, Document Date: 07/11/2013,
http://www.section508.gov/documents/final-far-rule-implementing-section-508-rehab-act
•
ICE Architecture Test and Evaluation Plan – Available upon request
•
ICE Enterprise Systems Assurance Plan – Available upon request
•
ICE System Lifecycle Management (SLM) Handbook – Available upon request
•
ICE Technical Reference Model (It is understood that the proposed TECS Modernization ICM
system would be reviewed as an emerging technology within the ICE SLM and TRM/Information
Technology Change Request processes) – Available upon request
•
NIST FIPS 201-2 ―Personal Identity Verification (PIV) of Federal Employees and Contractors,
August 2013, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-2.pdf
•
NIST SP 800-63-1: Electronic Authentication Guideline (December 2011),
http://www.nist.gov/customcf/get_pdf.cfm?pub_id=910006
•
OMB M-06-16 ―Acquisition of Products and Services for Implementation of HSPD-12, June 23,
2006, http://www.whitehouse.gov/sites/default/files/omb/memoranda/fy2006/m06-16.pdf
•
OMB M-10-15 ―FY 2010 Reporting Instructions for the Federal Information Security
Management Act and Agency Privacy Management, Issued April 21, 2010,
http://www.whitehouse.gov/sites/default/files/omb/assets/memoranda_2010/m10-15.pdf
•
OMB M-11-11 "Continued Implementation of Homeland Security Presidential Directive (HSPD)
12– Policy for a Common Identification Standard for Federal Employees and Contractors" ,
February 3, 2011, http://www.whitehouse.gov/sites/default/files/omb/memoranda/2011/m1111.pdf
•
Privacy Act of 1974, http://www.justice.gov/opcl/privstat.htm
•
Federal Information Processing Standard (FIPS) 199
http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf
•
Federal Information Security Management Act (FISMA), November 22, 2002
http://csrc.nist.gov/drivers/documents/FISMA-final.pdf
Statement of Objectives
Version 1.0
Page: 29

Appendix A - List of Acronyms
Acronym
Description
AD
Active Directory
CBP
Customs and Border Protection
CLIN
Contract Line Item Number
COTS
Commercial Off-the-Shelf
CWBS
Contractor Work Breakdown Structure
DHS
Department of Homeland Security
DTaaS
Development Test as a Service
FOC
Full Operational Capability
GFE
Government Furnished Equipment
GFP
Government Furnished Property
HSI
Homeland Security Investigations
IaaS
Infrastructure as a Service
ICE
Immigration and Customs Enforcement
ICM
Investigative Case Management
IOC
Initial Operational Capability
IPT
Integrated Project Team
KPP
Key Performance Parameter
MOE
Measure of Effectiveness
NCIC
National Crime Information Center
NLETS
National Law Enforcement Telecommunications Systems
O&M
Operations and Maintenance
OCIO
Office of Chief Information Officer
OIT
Office of Information Technology
OPR
Office of Professional Responsibility
POP
Period of Performance
PSR
Person Subject Record
PWS
Performance Work Statement
RACI
Responsible, Accountable, Consulted, Informed
RDBMS
Relational Database Management System
RFP
Request for Proposal
ROI
Reports of Investigation
Statement of Objectives
Version 1.0
Page: 30

Acronym
Description
SAML
Security Assertion Markup Language
SCI
Sensitive Compartmented Information
SCO
System Control Officer
SELC
Systems Engineering Life Cycle
SLM
System Lifecycle Management
SOO
Statement of Objectives
SSO
Single Sign On
TECS
Treasury Enforcement Communication System
TEMP
Test and Evaluation Master Plan
TLS
Telephone Linking System
TMP
Transition Management Plan
TRM
Technical Reference Model
VM
Virtual Machine
VPN
Virtual Private Network
VSR
Vehicle Subject Record
WAM
Web Access Management
Statement of Objectives
Version 1.0
Page: 31