(Pre-Solic) 20170403 - Revised Draft Solicitation.docx.mcgn5pg.partial

N65236-16-R-0001

Section B - Supplies or Services and Prices

ITEM NO

SUPPLIES/SERVICES

EST QUANTITY

UNIT

Advanced Analytics Technical Solution

Delivery of Advanced Analytics Technical Solution (AATS) Software in accordance with the Performance Work Statement

FFP

ITEM NO

EST QUANTITY

UNIT

Advanced Analytics Technical Solution

Delivery of AATS Software Documentation/Technical Data Package in accordance with Performance Work Statement

ITEM NO

EST QUANTITY

UNIT

Advanced Analytics Technical Solution

Delivery of AATS Systems Approach Training (SAT) Materials in accordance with Performance Work Statement

Advanced Analytics Technical Solution

Original Equipment Manufacturer (OEM) / Subject Matter Expert (SME) Support Services for AATS Integration, Configuration, System Administration, Test, and IA in accordance with the Performance Work Statement.

Note – There will be Only One CLIN for this item, but the RFP pricing model will allow the contractor to propose different labor rates/price estimates by contract year.

MAX NET AMT

CEILING PRICE

FFP-LOE

__27,900___

ITEM NO

EST QUANTITY

UNIT

Advanced Analytics Technical Solution

Contract Year 2 - Annual Sustainment for AATS Software Delivered Under CLIN 0001, including Annual Software Updates and Security Updates in accordance with the Performance Work Statement

ITEM NO

EST QUANTITY

UNIT

Advanced Analytics Technical Solution

Contract Year 3 - Annual Sustainment for AATS Software Delivered Under CLIN 0001, including Annual Software Updates and Security Updates in accordance with the Performance Work Statement

ITEM NO

EST QUANTITY

UNIT

Advanced Analytics Technical Solution

Contract Year 4 - Annual Sustainment for AATS Software Delivered Under CLIN 0001, including Annual Software Updates and Security Updates in accordance with the Performance Work Statement

ITEM NO

EST QUANTITY

UNIT

Advanced Analytics Technical Solution

Contract Year 5 - Annual Sustainment for AATS Software Delivered Under CLIN 0001, including Annual Software Updates and Security Updates in accordance with the Performance Work Statement

Advanced Analytics Technical Solution

AATS Pre-Planned Product Improvements in accordance with the Performance Work Statement

Note – There will be Only One CLIN for this item, but the RFP pricing model will allow the contractor to propose different labor rates/price estimates by contract year.

MAX NET AMT

CEILING PRICE

__34,560___

FFP-LOE

ITEM NO

EST QUANTITY

UNIT

CDRLs

Contract Data Requirements List (CDRLs) in accordance with Performance Work Statement - Not Separately Priced

ITEM NO

EST QUANTITY

UNIT

Advanced Analytics Technical Solution

Contract Years 2 Through 5 - Additional AATS Annual Software Licenses/User Capacity, including License Agreement, Annual License Renewals, Software Updates, and Security Updates For Additional AATS Software Users Through End of Contract Performance Period, in accordance with the Performance Work Statement - Note - Additional AATS Software Licenses/User Capacity Will Be Purchased in Lots of 100, where 1 Lot is equal to 100 Additional Concurrent Users

ITEM NO

EST QUANTITY

UNIT

Travel and Other Direct Costs

The contractor shall perform in accordance with PWS paragraph 14.0. Not-To-Exceed $286,293. Specific requirements will be priced at the task order level.

CLAUSES INCORPORATED BY FULL TEXT

5252.216-9218 MINIMUM AND MAXIMUM QUANTITIES (JUL 1989)

As referred to in paragraph (b) of the “Indefinite Quantity” clause of this contract, the contract minimum quantity is a total of $25,000 worth of orders at the contract unit price(s). The contract minimum quantity will be satisfied via the issuance of Delivery Order 0001, which will be issued concurrently with contract award (see solicitation Attachment 13 – Delivery Order 0001 Statement of Work). The maximum quantity is the total estimated amount of the contract. The maximum quantity is not to be exceeded without prior approval of the Procuring Contracting Officer.

(End of clause)

NOTE

Solicitation Attachment 14 provides a cross reference of Contract Line Item Numbers (CLINs) to PWS Sections.

Section C - Descriptions and Specifications

SPECIFICATIONS/WORK STATEMENT

Work under this performance-based contract shall be performed in accordance with the following description/ specifications/ statement of work (SOW) which herein shall be referred to as Performance Work Statement (PWS):

1.0 PURPOSE

1.1 BACKGROUND

The Space and Naval Warfare Systems Center (SPAWARSYSCEN) Atlantic, Expeditionary Intelligence Solutions (EIS) Portfolio, Distributed Common Ground Surface/System (DCGS) Marine Corps Integrated Product Team, Intelligence Analysis System (IAS) program supports the United States Marine Corps (USMC) all-source intelligence analyst (Military Occupational Specialty (MOS) 0231) in the processing, exploitation, analysis, interpretation, and presentation of all-source intelligence data. The IAS Family of Systems (IAS FoS) provides support to multiple echelons, from the Marine Expeditionary Force (MEF) to the Company level, through the employment of intelligence servers and workstations. The Intelligence Server – Windows (IS-W) is a physical server with VMWare ESXi hypervisor installed, and hosts multiple virtual machines that provide collaboration, track management, and common operational picture (COP) services for the intelligence analyst, and provides access to Global Command and Control System – Joint (GCCS-J) and GCCS- Integrated Intelligence and Imagery (GCCS-I3) services. The IS-W is deployed at all levels of the Marine Air Ground Task Force (MAGTF) down to the regimental echelon and Marine Expeditionary Units (MEU). Intelligence Workstations (IW) are present at all echelons of the MAGTF down to the Company level, can utilize services on the IS-W (Modernized Integrated Database (MIDB), COP, chat, etc.), and can also operate in standalone mode.

Advancements in the technology fields of knowledge management and data science present opportunities to introduce efficiencies in the intelligence cycle (Marine Corps Doctrinal Publication (MCDP 2-1) through utilization of ontologies to structure data from disparate sources as well as integration of predictive analytics, natural language processing, and related technologies; and the use of emerging and non-traditional database technologies and architectures to support the efficient search and retrieval of information. Therefore, the IAS program has initiated an Advanced Analytics Technical Solution (AATS) project to identify and acquire an enterprise-capable software solution that supports the activities and intent of each phase of the intelligence cycle, reduces manual effort through application of advanced analytics technologies, and functions in both connected and disconnected modes of operation. “Enterprise-capable” software solution means the software must provide capability that scales to the available computing resources at each echelon. “Connected and disconnected modes of operation” primarily refers to the ability of the IW to communicate with the IS-W over the network. It can also refer to the connectivity of the IW and the IS-W to the Marine Corps Enterprise Network (MCEN).

1.2 SCOPE

The scope of this PWS includes the procurement of an advanced analytics software product, using commercial item (CI) or non-developmental item (NDI) components (see Federal Acquisition Regulation 2.101 for the definition of commercial item and non-developmental item) to the maximum extent practicable, that will 1) assist with the processing, exploitation, analysis, interpretation, and presentation of all-source intelligence data; and 2) include a robust, open application programming interface (API) that provides extensive support for integration of Government-developed and commercially-developed application plugins and integration between AATS data storage and external data sources. The software will minimize total ownership costs, and will accommodate the characteristics of the user population that will operate, maintain, and support the software without support from Field Service Representatives (FSRs) and the key missions, operations, and decisions that the software must support.

The scope of this PWS may include non-commercial development that is layered over the CI or NDI components. the development of layer will allow for a more a robust, open application programming interface (API) that provides extensive support for integration of Government-developed and commercially-developed application plugins and integration between AATS data storage and external data sources, both the IS-W and at the IW’s. The non-commercial development, when combined with the APIs will allow for a modular open software environment, which can support substitution of either commercial products or the non-commercial layer, on either side of the API, and at both the IS-W and at the IW.

The scope also includes the services required to support SPAWARSYSCEN Atlantic personnel in the engineering, integration, information assurance, testing, and training activities required for the program to deploy the software to the MEF within the IAS architecture; and to ensure that SPAWARSYSCEN Atlantic personnel can maintain the software on the IAS baseline without additional vendor support. The Program Sponsor is the Marine Corps Systems Command (MARCORSYSCOM).

The AATS software shall support the following tiered IAS FoS composition:

· IAS-FoS, Tier I (20 fielded systems): The Tier I of the IAS FoS is the MEF IAS which supports the MEF Command Element in garrison and deployed.

· IAS-FoS, Tier II (132 fielded systems): The Tier II of the IAS FoS is made up of Intelligence Servers which are cased into transportable server suites. The Intelligence Server Unix is UNIX-based and supports the Marine Divisions, Marine Aircraft Wings, Marine Logistics Groups, and Intelligence Battalions. The Intelligence Server Windows is Windows-based and supports Marine Expeditionary Units, infantry and artillery regiments, and air groups.

· IAS-FoS, Tier III (2574 fielded systems): The Tier III of the IAS FoS is made up of Intelligence Workstations which are man-portable, Windows-based systems that support battalions, squadrons, companies, and select higher echelon headquarters.

NOTE: Work will not be performed in Afghanistan.

2.0 APPLICABLE DOCUMENTS (AND DEFINITIONS)

2.1 REQUIRED DOCUMENTS

The following instructional documents are mandatory for use during contract performance. Unless otherwise specified, the document’s effective date of issue is the date on the request for proposal. Additional applicable documents may be included in specific task orders.

c.

DoD Instruction – Risk Management Framework (RMF) for DoD Information Technology (IT), dtd 12 Mar 14

Information Assurance Workforce Improvement Program, dtd 19 Dec 05 with Change 3, dtd 24 Jan 12

2.2 GUIDANCE DOCUMENTS

The following documents are to be used as guidance during contract performance. Unless otherwise specified, the document’s effective date of issue is the date on the request for proposal. Additional applicable documents may be included in specific task orders.

2.3 SOURCE OF DOCUMENTS

The contractor shall obtain all applicable documents. Many documents are available from online sources. Specifications and commercial/industrial documents may be obtained from the following sources:

Copies of Federal Specifications may be obtained from General Services Administration Offices in Washington, DC, Seattle, San Francisco, Denver, Kansas City, MO., Chicago, Atlanta, New York, Boston, Dallas and Los Angeles.

Copies of military specifications may be obtained from the Commanding Officer, Naval Supply Depot, 3801 Tabor Avenue, Philadelphia, PA 19120-5099. Application for copies of other Military Documents should be addressed to Commanding Officer, Naval Publications and Forms Center, 5801 Tabor Ave., Philadelphia, PA 19120-5099.

All other commercial and industrial documents can be obtained through the respective organization’s website.

3.0 PERFORMANCE REQUIREMENTS

The following paragraphs list all products and services that shall be required throughout the contract life. The contractor shall provide necessary resources and knowledge to support the listed supply and services requirements. Specific objectives will be dependent on the basic contract and the delivery/task order (TO) written against the basic contract. The contractor shall complete all required deliveries/tasks while controlling and tracking performance and goals in terms of price, schedules, and resources.

Note: In compliance with SPAWARINST 4720.1A – SPAWAR Modernization and Installation Policy, all contract installation work performed aboard Navy ships and Navy shore sites is under Installation Management Office (IMO) supervision; otherwise, a formal exemption request has been approved. In accordance with the Fleet Readiness Directorate Standard Operating Procedure (FRD SOP), COMSPAWARSYSCOM letter Ser FRD/235 dated 24 Apr 12, the contractor shall ensure proper notification and status updates of installation work performed outside of SPAWARSYSCEN Atlantic respective Areas of Responsibilities (AORs) are provided to the SPAWAR Officer in Charge (OIC) or applicable Geographic Lead.

3.1 Open Systems Approach

The AATS software product shall, to the maximum extent practicable, have an Open System Architecture and corresponding components. The contractor shall define, document, and follow an open systems approach for using modular design, standards-based interfaces, and widely-supported consensus-based standards. The contractor shall develop, maintain, and use an Open System Management Plan (CDRL A002) to support this approach and shall demonstrate compliance with that plan during all design reviews.

In satisfying the Government’s requirements, the following system architecture approach characteristics shall be utilized:

3.1.1 Open Architecture

The contractor’s AATS software product shall encompass an architecture that incorporates appropriate considerations for re-configurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and long-term supportability. The contractor architecture shall include well-defined interfaces that allow for substitution of components on either side of the interface.

The contractor shall ensure that external information exchange requirements are implemented in a standard and open manner as part of this effort. These actions shall include planning that identifies the contractor’s specific approach to ensuring software and interface data is well-defined, available to all programs, and uses a standards-based tool for definition within the context of DoD and Service upgrade programs.

3.1.2 Modular, Open Design

The contractor shall provide an AATS software product with an architecture that is layered and modular and uses standards-based commercial item/NDI software, operating systems, and middleware that shall utilize either non-proprietary or non-vendor-unique key module or component interfaces where available. Any software components, applications or software or interface data that are developed under the contract will be considered non-commercial software that is developed at Government expense. The contractor’s design approach shall be consistent throughout all subsystems and components.

Module Coupling – The contractor’s design approach shall result in modules that have minimal dependencies on other modules (loose coupling), as evidenced by simple, well-defined interfaces and by the absence of implicit data sharing. The purpose is to ensure that any changes to one module will not necessitate extensive changes to other modules, and hence facilitate module replacement and system enhancement.

Module Cohesion – The contractor’s design shall result in modules that are characterized by the singular assignment of identifiable and discrete functionality (high cohesion). The purpose is to ensure that any changes to system behavioral requirements can be accomplished by changing a minimum number of modules within the system.

System Requirements Accountability – The contractor shall ensure that all software requirements in this PWS are accounted for through a demonstrated ability to trace each requirement to one or more modules that consist of components that are self-contained elements with well-defined, open, and published interfaces implemented using open standards.

Inter-component Dependencies – The contractor’s design approach shall result in a layered system design, maximizing software independence from the hardware, thereby facilitating technology refresh. The design shall be optimized at the lowest component level to minimize inter-component dependencies. The layered design shall also isolate the application software layers from the infrastructure software (such as the operating system) to enhance portability and to facilitate technology refresh. The design shall be able to survive a change to the computing infrastructure with minimal or no changes required to the application logic. The interfaces between the layers shall be built to open standards or the technical data describing the interface shall be available to the Government with at least Government Purpose Rights. The software architecture shall minimize inter-component dependencies to allow components to be decoupled and reused, where appropriate, across various DoD or Service programs and platforms.

3.1.3 Technology Insertion

The contractor’s architectural approach shall support the rapid and affordable insertion and refreshment of technology through modular design, the use of open standards and open interfaces. The contractor shall define the functional partitioning and the logical modularity of the system software subsystems and components to facilitate future replacement of specific subsystems and components without impacting other parts of the system and to encourage third-party vendor’s participation.

3.1.4 Life Cycle Management and Open Systems

The contractor’s architecture shall provide for insertion of commercial items into the system and, as directed at the delivery order/task order level, (a) demonstrate that commercial item, reusable NDI, and other components are logistically supported throughout the life cycle, (b) describe and demonstrate the strategy for reducing product or system and associated supportability costs through insertion of commercial items and other reusable commercial item or NDI products, (c) establish a process to logistically support commercial item or NDI products, and (d) shall provide the proposed methodology for pass through of commercial item warranties to the Government.

3.1.5 Use of Standards

The contractor’s architectural approach shall use the following standards in descending order of importance:

Standards as specified within the contract, including task orders.

Commercial standards:

Standards developed by international or national industry standards bodies that have been widely adopted by industry. Examples of widely adopted standards are:

SQL for databases (e.g., SQL for databases ANSI ISO/IEC 9075-1, ISO/IEC 9075-2, ISO/IEC 9075-3, ISO/IEC 9075-4, ISO/IEC 9075-5)

HTML for presentation layer (e.g., XML 1.0 www.webstandards.org)

JSON for data transfer

Web services for remote system calls

Standards adopted by industry consensus-based standard bodies and widely adopted in the market place.

De facto standards (those widely adopted and supported in the market place).

Note: Standards that are not specified within this contract or that are modified shall be submitted to and approved by the Government Program Manager prior to use.

3.1.6 Life Cycle Sustainability

The contractor shall consider use of commercial items/NDI and open standards to enhance the system’s life cycle sustainability by implementing performance-based logistics (PBL) arrangements to sustain the components through their life cycle.

3.1.7 Interface Design and Management

The contractor shall:

Clearly define, identify and describe all component and system interfaces;

Define and document all subsystem and configuration item (CI) level interfaces to provide full functional, logical, and physical specifications;

Identify the interface and data exchange standards between the component, module or system and the interconnectivity or underlying information exchange medium;

Use the identified interfaces to support an overall information assurance strategy that implements Information Assurance (IA) Processes in accordance with DoD Instruction 8500.2 (dated February 6, 2003) and;

If applicable, select external interfaces from existing open or Government standards with an emphasis on enterprise-level interoperability. The contractor shall describe how its selection of interfaces will maximize the ability of the system to easily accommodate technology and facilitate the insertion of alternative or reusable modular system elements on either side of the interface.

3.1.8 Treatment of Proprietary or Vendor-Unique Elements

The contractor shall explain the use of proprietary, vendor-unique or closed components or interfaces. If applicable, the contractor shall define its process for identifying and justifying proprietary, vendor-unique or closed interfaces, code modules, hardware, firmware, or software to be used. When interfaces, hardware, firmware, or modules that are proprietary or vendor-unique are required, the contractor shall demonstrate to the Government that those proprietary elements do not preclude or hinder other component or module developers from interfacing with or otherwise developing, replacing, or upgrading open parts of the system.

3.2. SOFTWARE PERFORMANCE SPECIFICATION

Within 90 days after date of contract (ADC) and concurrent issuance of Delivery Order 0001, the contractor shall deliver an AATS software solution ready for functional integration into the IAS system baseline in accordance with the requirements of this section (CLIN 0001).

3.2.1 Technical Maturity (CLIN 0001)

The AATS software shall support the capabilities defined in this specification and its attachments, either out of the box or with configuration changes.

The components and modules of the proposed AATS software shall have been previously integrated and deployed together in a similar production environment as defined in this specification.

3.2.2 Software Compatibility (CLIN 0001)

Background

The Government will install and integrate the AATS software into the IAS system baseline, using the AATS documentation deliverables. The Government does not intend to introduce additional hardware into the IAS system baseline to support the system requirements of the AATS software. Therefore, the AATS software must function within the hardware and software constraints of the IAS system baseline at the time of award.

AATS Software Requirements

3.2.2.1 Vendor-specified system requirements for AATS software components installed on the IW shall not exceed the IW hardware and software specification (Solicitation Attachment 6).

3.2.2.2 Vendor-specified system requirements for AATS software components installed on the IS-W shall not exceed the IS-W hardware and software specification (Solicitation Attachment 6).

3.2.2.3 AATS software components installed on the IS-W shall be capable of operating in Virtual Machines (VMs) managed by VMWare ESXi hypervisor software.

3.2.2.4 AATS software components installed on the IS-W shall be compatible with Microsoft Server 2012 Operating System or Red Hat Linux 7.

3.2.2.5 AATS software components installed on the IW shall be compatible with Microsoft Windows 10 Operating System.

3.2.2.6 AATS software components that require the use of a web browser shall be fully compatible with the web browser software versions listed in the IS-W and IW software specification (Solicitation Attachment 6). Updates to the AATS software components shall be provided to maintain compatibility with updates to the web browser software on the IS-W and IW software baselines.

3.2.3 Information Assurance (CLIN 0001)

The AATS software package shall be compliant with all applicable Defense Information Systems Agency (DISA) information assurance requirements as provided in DISA Security Requirement Guides (SRGs) and Security Technical Implementation Guides (STIGs).

3.2.4 Supportability

3.2.4.1 Once fielded as part of the IAS software baseline to the end users, the AATS software package and all functionality provided by the AATS software package shall be capable of being maintained without on-site contractor support. (CLIN 0001)

3.2.4.2 The contractor shall provide any and all AATS software package version upgrades as they are released and no less than semiannually. (CLINs 0001, 0005, 0006, 0007, 0008, and 0011)

3.2.4.3 The contractor shall provide additional AATS software, license agreements, software updates, and security updates, as applicable, to support and expand the IAS FoS Authorized Acquisition Objective (AAO) in increments of 100. (CLIN 0011)

3.2.4.4 Upon notification of a security vulnerability in the AATS software package or its dependencies, the contractor shall provide a fix or mitigation strategy according to the following timetable (CLIN 0005, 0006, 0007, 0008, and 0011):

3.2.4.5 All AATS software package version upgrades shall support non-destructive updates of the IAS software baseline. Software requirements that support non-destructive updates include, but are not limited to (CLIN 0005, 0006, 0007, 0008, and 0011):

All software package version upgrades shall support silent installation (installation with no user interaction required).

All software package version upgrades shall support scripted installation, where all installation parameters are accessible at the command line.

3.2.5 Functional Requirements (CLIN 0001)

3.2.5.1 Database and Ontology

Background/Definitions

In order to promote data consistency and interoperability between organizationally and/or geographically disparate USMC intelligence teams, and to provide a framework for the development of advanced analytical capabilities, the AATS software will conform all processed data to a Government-provided AATS ontology. “Processed data” means structured, semi-structured, and unstructured data from external sources that has been mapped to objects, relationships, and properties defined by the ontology. The standard form of the Government-provided ontology will be the XML/RDF serialization defined by the W3C OWL 2 Web Ontology Language XML Serialization (Second Edition).

The following definitions will be used for the AATS software requirements:

An Object Type is an abstract concept; for example, “Person”, “Equipment”, “Event”, and “Facility”.

An Object is an instance of an Object Type. Using the “Person” Object Type example, the user may create Objects from the “Person” Object Type that represent specific people (e.g. “John Doe”).

A Relationship Type is an abstract relation where the domain and range are Object Types. For example:

A Relationship is an instance of a Relationship Type (in the same way that an Object is an instance of an Object Type). Continuing the “is-located-at” Relationship Type example, the following are examples of valid Relationships:

“John Doe” (Person Object) “is-located-at” (Relationship) “Building XYZ” (Facility Object)

A Property Type is a specification of an attribute and its range of valid values. Some examples:

Height: positive integer

Body Style: “Sedan”, “Coupe”, “Truck”

Name: Unicode string

Property Types will be incorporated into the specification of one or more Object Types and Relationship Types. As part of the specification, Object Types and Relationship Types will identify additional constraints such as cardinality, required/not required, etc. For example:

A Property is an instance of a Property Type in an Object or Relationship. Using the “Person” Object Type specification above, a valid Object could be:

AATS Software Requirements

3.2.5.1.1 The software shall include a database that supports the storage, management, and retrieval of Objects, Relationships, and Properties as defined by the Government-provided AATS ontology.

3.2.5.1.2 The software shall import and export the Government-provided AATS ontology in Web Ontology Language (OWL) 2 compliant RDF/XML format.

The contractor shall provide the Government with all ontology implementation requirements necessary to provide the capability defined in this specification (CDRL A002).

If the contractor requires that the Government-provided AATS ontology include or import XML schemas or ontologies, the contractor shall provide an electronic copy of the required documents (CDRL A002).

The combination of the Government-provided AATS ontology and any modifications to the Government-provided AATS ontology required by the contractor’s ontology implementation requirements and/or contractor-provided XML schemas or ontologies shall result in an OWL 2 compliant RDF/XML ontology.

The ontology implementation requirements shall not restrict the ability of the Government to define direct subclasses of the OWL 2 Class “owl:Thing”.

3.2.5.1.3 The software shall provide the capability to create new ontologies.

3.2.5.1.4 The software shall allow the combination of multiple ontologies so as to construct the overall ontology.

3.2.5.1.5 The software shall provide the capability to update the ontology, both via the software user interface and via the import of an updated Government-provided AATS ontology.

3.2.5.1.6 Prior to committing ontology changes, the software shall provide the capability to map existing data to the new ontology without data loss.

If the software is unable to map existing data to the new ontology without data loss, the software shall provide a report that identifies the data that will be lost as a result of the ontology update.

3.2.5.1.7 Prior to committing ontology changes, the software shall provide the capability to update mappings between data sources and data element mappings (see Section 3.2.5.2.3.3)

3.2.5.1.8 The software shall provide the capability to deploy the ontology to other instances of the AATS database.

3.2.5.1.9 The software shall provide the capability to visualize the ontology.

3.2.5.1.10 The software shall ensure that all data stored in the database is validated against the ontology.

The software shall support the use of Relationship Properties as defined in the Government-provided AATS ontology.

The software shall support the use of required Properties for Objects and Relationships as defined in the Government-provided AATS ontology.

3.2.5.1.11 The software shall support the Object Type taxonomy defined in the Government-provided AATS ontology.

3.2.5.1.12 The software shall support the Relationship Type taxonomy defined in the Government-provided AATS ontology.

3.2.5.1.13 The software shall provide the capability to deprecate Object Types such that no new Objects of that type can be created, and existing Objects of that type can be used in the search and analysis capabilities of the software.

3.2.5.2 Data Entry

Background

The processing and exploitation phase of the intelligence cycle involves the conversion of structured, semi-structured, and unstructured data into information that is suitable for the production of intelligence to satisfy intelligence requirements. The AATS software will provide manual, assisted, and automated data entry capabilities to support this phase of the intelligence cycle.

AATS Software Requirements

The software shall support the processing of structured, semi-structured, and unstructured data into Objects, Relationships, and Properties conformant with the Government-provided AATS ontology.

3.2.5.2.1 Manual Data Entry

3.2.5.2.1.1 The software shall allow the user to create and update Objects.

3.2.5.2.1.2 The software shall allow the user to set and update Property values for an Object.

3.2.5.2.1.3 When Property values for an Object are updated, the software shall preserve the history and attribution of changes to the Property value.

3.2.5.2.1.4 The software shall allow the user to create and update Relationships between Objects.

3.2.5.2.1.5 The software shall allow the user to archive Relationships between Objects.

3.2.5.2.1.6 The software shall allow the user to set and update Property values for a Relationship.

3.2.5.2.1.7 When Property values for a Relationship are updated, the software shall maintain the history and attribution of changes to the Property value.

3.2.5.2.1.8 The software shall allow the user to attach files to an Object.

3.2.5.2.1.9 The software shall allow the user to link an attachment to a specific Property.

3.2.5.2.1.10 The software shall allow the user to define a default image per Object Type.

3.2.5.2.1.11 The software shall allow the user to set a custom image per Object.

3.2.5.2.1.12 The software shall allow the user to define a default MIL-STD-2525D symbol for an Object Type.

3.2.5.2.1.13 The software shall allow the user to set the MIL-STD-2525D symbol for an Object.

3.2.5.2.1.14 The software shall allow the user to archive Objects. The archive operation shall archive the Relationships, Properties, and attachments for each archived Object.

3.2.5.2.1.15 The software shall allow the user to restore archived Objects.

3.2.5.2.1.16 The software shall exclude archived data from user searches unless the user specifies that archived data should be included in the search results.

3.2.5.2.1.17 The software shall exclude archived data from replication unless the user requests the inclusion of archived data.

3.2.5.2.1.18 The software shall allow the user to merge Objects.

3.2.5.2.1.19 The software shall allow the user to merge Relationships.

3.2.5.2.1.20 The software shall allow the user to assign a confidence value for the Object and the Properties for the Object.

3.2.5.2.1.21 The software shall allow the user to update the confidence value for the Object and the Properties for the Object.

3.2.5.2.1.22 The software shall allow the user to assign a confidence value for a Relationship and the Properties for the Relationship.

3.2.5.2.1.23 The software shall allow the user to update the confidence value for a Relationship and the Properties for the Relationship.

3.2.5.2.1.24 All Objects shall be labeled in accordance with (IAW) Intelligence Community Information Security Markings Metadata (ICISM) standards

3.2.5.2.1.25 All Relationships shall be labeled IAW ICISM standards.

3.2.5.2.1.26 All Property values shall be labeled IAW ICISM standards.

3.2.5.2.1.27 The classification for the Object should be equal to the highest Property value classification for the Object.

3.2.5.2.2 Tagging

Background

The tagging capability assists the user in creating structured data from unstructured or semi-structured documents. The user is able to identify and select Objects and Relationships in a document, and the AATS software identifies potential matches to those Objects in the AATS database. Via the tagging process, the user is able to associate the selected Object or Relationship to the AATS-identified match, or is able to create a new Object or Relationship from the selection that will be stored in the AATS database.

AATS Software Requirements

3.2.5.2.2.1 The software shall allow the user to tag Objects in documents.

3.2.5.2.2.2 The software shall allow the user to tag Relationships in documents.

3.2.5.2.2.3 The software shall identify to the user potential matches between tagged items and existing Objects and Relationships in the database.

The software shall allow the user to view and edit matches to tagged items.

3.2.5.2.2.4 The software shall allow the user to create Objects or Relationships from tagged items.

3.2.5.2.3 Automated Ingest

Background

The automated ingest capability provides for unattended conversion of intelligence data and information into Objects and Relationships. Data sources for the automated ingest capability include local and networked file storage, external databases, and web services. Data formats include documents, spreadsheets, and presentations, geospatial data files, United States Message Text Format (USMTF) messages, and other domain-specific formats. Objects and Relationships that are created by the software as a result of automated ingest will identify the source of the data, a reference to the data source (typically a Uniform Resource Indicator), and will maintain a copy of the data that was used to create the Object or Relationship. File content will be fully indexed to enable searching within documents via the search/query user interface.

AATS Software Requirements

3.2.5.2.3.1 The software shall provide the capability to ingest structured and semi-structured data from local and networked file storage, external databases, and web services.

3.2.5.2.3.2 The software shall provide the capability to map data elements from structured and semi-structured data sources to Objects, Relationships, and Properties.

3.2.5.2.3.3 The software shall provide the capability to associate data element mappings with specific data sources.

3.2.5.2.3.4 The software shall provide the capability to configure and execute a schedule for ingest of structured and semi-structured data.

3.2.5.2.3.5 The software shall allow the user to specify a local file source for automated ingest.

3.2.5.2.3.6 The software shall monitor specified file sources and automatically ingest new and modified files.

3.2.5.2.3.7 The software shall process all ingested files for Object and Relationship extraction.

The software shall identify Objects and Object Properties in processed files.

The software shall identify Relationships and Relationship Properties in processed files.

3.2.5.2.3.8 All ingested data shall retain the reference to the source of the data.

3.2.5.2.3.9 The software shall retain a source copy of the ingested data.

3.2.5.2.3.10 The software shall provide a capability to ingest data from the following file types:

3.2.5.2.3.11 The software shall prevent duplicate files from being ingested.

3.2.5.2.3.12 The software shall automatically transform invalid Property values entries into allowable values.

3.2.5.2.3.13 The software shall allow the user to map ingested raw data elements to the ontology.

3.2.5.2.3.14 The software shall allow the user to associate raw data element mapping to specific data sources.

3.2.5.2.3.15 The software shall provide for a review of all automatically transformed Property values prior to committing to the AATS database.

3.2.5.2.3.16 Automated Ingest Review Capability

Background

The software shall have multiple safeguards against the generation of erroneous data from malformed or poorly structured data sources. These safeguards shall include a “dry run” ingest capability that, when executed, shall alert the analyst to potential ingest problems within the data source. It shall also provide the ability to review all auto-generated Objects and Relationships prior to committing to the database. Until this review has been performed, auto-generated Objects and Relationships shall be searchable but clearly identified as “pending review.”

AATS Software Requirements

The software shall mark all automatically-identified Objects, Relationships, and Properties as “pending review”.

The software shall provide the analyst with the capability to review and approve or reject Objects, Relationships, and Properties that are “pending review”.

The software shall provide a dry run ingest capability that alerts the analyst to potential problems with the source data.

3.2.5.3 Map Display

3.2.5.3.1 The software shall provide a map display.

3.2.5.3.2 The map display shall be capable of retrieving map images utilizing the Open Geospatial Consortium (OGC) Web Map Service (WMS) Interface standard.

3.2.5.3.3 The map display shall provide the display of data and map layers, and allow the user to toggle the layers on or off for viewing.

3.2.5.3.4 The software shall be capable of displaying map data in the following formats:

3.2.5.3.5 The software shall support the latitude and longitude, Military Grid Reference System (MGRS), and Universal Transverse Mercator (UTM) standard coordinate systems.

3.2.5.3.6 The map view shall support displaying Objects utilizing the defined image or symbol; or, if not available, the map view shall display the default image or symbol for an Object.

3.2.5.3.7 The map view shall be capable of displaying mensurated images.

3.2.5.4 Data Organization

Background

Operations, in the context of AATS, are a container for organizing data in support of intelligence analysis for a real-world operation. For example, “Operation Iraqi Freedom” could be a top-level container for data collected and included within the scope of the operation. Missions are similar to Operations on a smaller scale, but associated with an Operation (Operations have a one-to-many relationship to Missions). Finally, Area of Operations (AOs), Areas of Influence (AIs), Areas of Interest (AOIs), and Areas of Responsibility (AORs) are geospatially-based containers to organize data within an Operation or a Mission.

Note that data can be associated with multiple Operations, Missions, AOs, AIs, AOIs, and AORs – for example, hostile actors that support enemy forces in multiple Operations.

AATS Software Requirements

3.2.5.4.1 The software shall allow the user to create, view and update an operation.

3.2.5.4.2 The software shall allow the user to archive an operation.

3.2.5.4.3 The software shall allow the user to create, view and update missions.

3.2.5.4.4 The software shall allow the user to archive a mission.

3.2.5.4.5 The software shall allow the user to create, view and update an Area of Operations (AO) on a map.

3.2.5.4.6 The software shall allow the user to associate an AO to an operation.

3.2.5.4.7 The software shall allow the user to archive an AO and all associated data and files.

3.2.5.4.8 The software shall allow the user to create, view and update an Area of Influence (AI) on a map.

3.2.5.4.9 The software shall allow the user to associate an AI to an operation.

3.2.5.4.10 The software shall allow the user to archive an AI and all associated data and files.

3.2.5.4.11 The software shall allow the user to create, view and update an Area of Interest (AOI) on a map.

3.2.5.4.12 The software shall allow the user to associate an AOI to an operation.

3.2.5.4.13 The software shall allow the user to archive an AOI and all associated data and files.

3.2.5.4.14 The software shall allow the user to create, view and update an Area of Responsibility (AOR) on a map.

3.2.5.4.15 The software shall allow the user to associate an AOR to an operation.

3.2.5.4.16 The software shall allow the user to archive an AOR and all associated data and files.

3.2.5.5 Search

The software shall provide the user a search interface for conducting queries.

The software shall allow the user to save, retrieve, and execute queries.

The software shall allow the user create standing queries and the ability to convert saved queries to standing queries.

The software shall allow the user to define an alert based on standing queries.

The software shall notify the user, via the application user interface, when new data is available that matches a standing query.

The software shall notify the user, via the application user interface, when data associated with a standing query is modified or deleted.

Files processed by the data ingest capability shall be searchable via the search interface.

The software shall allow the user to query the full content of the files, including file metadata, via the search interface.

All Objects and Relationships shall be able to be queried via the search interface.

The software shall learn from user interaction with search results in order to improve relevance of search results.

3.2.5.5.1 Contextual Query

3.2.5.5.1.1 The software shall allow the user to conduct queries based on Property values and keywords.

3.2.5.5.1.2 The software shall allow the user to conduct queries based on Property values, multiple Property values, and keywords using ‘and’, ‘or’, and ‘not’ Boolean operators.

3.2.5.5.1.3 The software shall allow the user to conduct queries based on the exclusion of one or more Property values and keyword using ‘not’ Boolean operators.

3.2.5.5.1.4 The software shall attempt to automatically complete keywords entered in the contextual search field.

3.2.5.5.2 Geospatial Query

3.2.5.5.2.1 The software shall allow the user to conduct proximity queries relative to a point location.

3.2.5.5.2.2 The software shall allow…