The USIGS Architecture Compliance Checklist is intended to be used when reviewing the following:

• Requirements documents such as Mission Needs Statements (MNS), Capstone Requirements Documents (CRD), Operational Requirements Documents (ORD), and other statements of need
• Acquisition documents such as System/Segment Specifications (SSS), Software Requirement Specifications (SRS), Interface Control Documents (ICD), Interface Requirement Specifications (IRS), Statements of Work (SOW), and Request For Proposals (RFP)
• Planning and guidance documents such as the NIMA Business Plan, IGC Functional Managers Guidance, and USIGS Migration Plan
• Requests For Change (RFC) and Engineering Change Proposals (ECP) related to any of the above.

Compliance with the USIGS architecture should be evaluated throughout the life cycle of a program from initial concept development to fielding. Its purpose is to help ensure that system acquisitions comply with the architecture and fundamental principles of USIGS. Managers, developers, and engineers must use this checklist as guidance in their efforts to build USIGS. It should be used as a reference when developing requirements and specifications for acquisition. It should be used when reviewing RFCs and ECPs to ensure that proposed changes are compliant with the USIGS architecture. It should also be used when developing milestone review checklists (e.g., Design Review Checklist, Pre-Ship Review Checklist) to ensure that the acquisition is moving along a path toward USIGS compliance.

Waivers for non-compliance by NIMA system acquisition programs must be approved by the Chief, Systems Engineering Office. Waivers which imply non-compliance with the Joint Technical Architecture (including non-compliance with DII COE standards) must also be approved by the NIMA CIO, ASD(C3I), and USD(A&T). Waivers which imply non-compliance with DoDIIS procedures and standards must also be approved by the DoDIIS Management Board (DMB).

The USIGS Architecture Compliance Checklist provides pointers to USIGS Architecture and related documents. Information in these documents is not repeated in this checklist.

The goal for all NIMA acquisition/development programs is to maintain compliance with the USIGS Architecture, therefore, all items in this checklist should be answered as "yes". If not, then it is the responsibility of the program manager to follow one of the following alternatives:

1. Request and get approval for a waiver,
2. Coordinate and submit changes required to the USIGS Architecture which would allow the system being reviewed to be compliant, or
3. Modify the document being reviewed to make it comply with the USIGS Architecture.

The USIGS Operational Architecture Description (UOAD) describes the USIGS mission, activities, operational relationships, and the internal and external flow of information and services.

• Is the document consistent with the objectives stated within the UOAD? If not, should the UOAD be updated or should the document be corrected?
• Is the document consistent with the UOAD Activity Hierarchy (e.g., does it support one or more UOAD activities)? If not, should the UOAD be updated or is the requirement/capability out of the scope of USIGS?
• Is the document consistent with the UOAD Information Exchange Requirements Matrix? If not, should the UOAD be updated or is the requirement/capability out of the scope of USIGS?

The USIGS Technical Architecture (UTA) is a set of rules to be used to develop an integrated, interoperable USIGS. It identifies standards, conventions, guidelines, and new technological capabilities to support the USIGS operational requirements, concepts, and information flows. As a profile of the Joint Technical Architecture (JTA), the UTA also invokes mandatory JTA standards.

• Does the document require the use of relevant standards and standards profiles identified in the UTA (Table 3-2 and Paragraph 3.2.2)? Waivers must be obtained when standards and profiles deviate from those identified in the UTA.
• Does the document require the use of USIGS conventions as defined in the UTA (Paragraph 3.3)? Waivers must be obtained when implementations deviate from the USIGS conventions.
• Does the document require or suggest the use of relevant USIGS guidelines as defined in the UTA, (Paragraph 3.4)? Waivers for failure to do so are not required.
• Does the document describe software functions and services in terms of the USIGS Technical Reference Model (UTRM) (Paragraph 2.2)? USIGS requirements specifications should map functionality or describe functionality in terms of the Mission Specific Applications (defined in the UTA, Paragraph 2.2.1), Common Support Applications, Open Geospatial Exchange Services (defined in the UTA, Paragraph 2.2.2), Common Facilities (defined in the UTA, Paragraph 2.2.3), and Platform Services (defined in the UTA, Paragraph 2.2.4). Waivers for failure to do so are required.

The JTA and UTA require compliance with Defense Information Infrastructure Common Operating Environment (DII COE) specifications. The DII COE provides a foundation for building open systems. It provides a standard environment, a set of standard components, and a set of programming standards that describe how to add new functionality to the environment.

• Does the document require segmentation of software and databases in accordance with the rules in the DII COE Integration and Runtime Specification (I&RTS)?
• If the document describes a NIMA migration system does it require DII COE level 5 compliance as required by the EPIP? DII COE level 5 compliance is per the checklist provided in the DII COE Integration and Runtime Specification (I&RTS), Appendix B-5. Waivers must be obtained for migration systems that are not DII COE level 5 compliant as required by the EPIP.
• If the document describes a new USIGS acquisition, does it require at least DII COE level 5 compliance at IOC with a goal of achieving level 8 compliance? DII COE level 5 and 8 compliance is per the checklists provided in the DII COE I&RTS, Appendices B-5 and B-8 respectively. Waivers must be obtained for new acquisitions that are not delivered as DII COE level 5 compliant.

The USIGS Systems Architecture Description, Volume I: To-Be Description (USAD) describes the USIGS as a set of functional components and interfaces. These components and interfaces are related to activities in the Operational Architecture, mission specific application categories and common support services in the Technical Architecture, and data model views in the Conceptual Data Model.

• Is the document consistent with the System Element Interface Diagrams and System Information Exchange Matrix in the To-Be Description?
• Does each requirement/capability support a single functional component? If not, can the requirement/capability be decomposed into lower-level requirements/capabilities which do support a single functional component?
• Does each requirement/capability support a single functional component of the operational activities?
• Does each requirement/capability support a single interface associated with that functional component? Do they support the corresponding application program interface (API), media type, and data format?
• Does each requirement/capability support the information content, security attributes, and performance attributes?

The USIGS System Architecture Description, Volume II: USIGS Interoperability Profile (UIP) defines profiles of interface standards used to achieve interoperability among software components within the USIGS architecture. Minimum requirements for access and connectivity and critical data interchange standards are defined.

• Does the document require compliance to the UIP for interface requirements?
• Do new USIGS acquisitions comply with the UIP for interface definitions? Waivers must be obtained for new acquisitions that do not comply with the UIP.
• Do new interfaces to existing systems comply with the UIP or existing ICDs. Existing ICDs are used only when significant cost/schedule/performance benefits can be achieved without adversely impacting interoperability requirements.
• If the UIP does not already address the function or service under review, has an RFC to the UIP been concurrently submitted to address the new functionality required?

The USIGS Conceptual Data Model (UCDM) defines the data requirements for the USIGS community. The UCDM consists of the data models and data dictionaries that have been standardized for use across the USIGS. Data standardization is necessary for the efficient exchange of data either as an exchange format or in the method signatures (i.e., input and output parameters) of an API specification. Waivers must be obtained when implementations are not consistent with the UCDM.

• Does the document require conformance to the UCDM?
• If the document is a Logical Data Model or Physical Data Model, are its publicly visible entities and attributes a proper subset of the UCDM? If not, has an RFC to the UCDM been submitted concurrently with the document under review?
• If the document describes or references data exchange requirements or APIs, does it require all exchanged data elements (except formatting artifacts) to use data elements from the UCDM? If not, has an RFC to the UCDM been submitted concurrently with the document under review?

The USIGS Evolutionary Phased Implementation Plan (EPIP) documents the evolution of the USIGS from its current As-Is state to its planned To-Be state.

• Is the document consistent with the functionality, interface requirements, performance requirements, and schedules identified in EPIP effectivities? If not, have issues been identified to the USIGS Migration Engineering Panel (UMEP) with corresponding action items assigned?

The USIGS Test, Evaluation, Transition, and Integration Plan defines the testing, evaluation, transition, and integration philosophies and policies and it provides guidance for these areas. It documents test criteria, methods and overall test planning. Testing details are provided in lower tier Test, Evaluation, Transition, and Integration Plans and Procedures.

• Is formal integration testing being performed at the Joint Interoperability Test Facility (JITF) planned and documented for capabilities that are being delivered to DoDIIS sites? Waivers must be obtained when integration testing at the JITF is not performed for capabilities being delivered to DoDIIS sites.
• Is formal interoperability testing being performed at the Joint Interoperability Test Command (JITC) planned and documented for capabilities that are being delivered to DoDIIS sites? Waivers must be obtained when interoperability testing at the JITC is not performed for capabilities being delivered to DoDIIS sites.
• Is formal security testing being performed by the Defense Intelligence Agency (DIA) planned and documented for capabilities that are being delivered to DoDIIS sites? Waivers must be obtained when security testing at the JITF is not performed for capabilities being delivered to DoDIIS sites.
• Is formal DII COE testing being performed by NIMA/SN and managed by NIMA/SE planned and documented? Waivers must be obtained when DII COE compliance testing is not performed by NIMA/SN.
• Is validation of Y2K compliance being performed prior to 31 December 1998? Validation of Y2K compliance is the responsibility of the appropriate PEO with oversight by the ADD/S.

Waivers must be obtained for deviations from Paragraphs 1 through 6 unless otherwise noted. To obtain a waiver, a full justification for the waiver, including technical, cost, schedule, and performance impacts must be provided to the Chief, Systems Engineering Office. The waiver request form, Attachment I, should be used when requesting a waiver. The form must be submitted to the Chief of Systems Engineering at least 180 days prior to the programs next major milestone.

The following is a list of documents that are referenced in this checklist.

• USIGS Technical Architecture (UTA), 6 November 1997
• USIGS Operational Architecture Description (UOAD), 26 May 1998
• USIGS System Architecture Description, Volume I: To-Be Description, (TBD)
• USIGS System Architecture Description, Volume II: USIGS Interoperability Profile (UIP), USIGS 1.0 Baseline, USIGS 1.5/2.0 Preliminary Baseline, 24 March 1998
• Evolutionary Phased Implementation Plan (EPIP), FY98, Draft E1.5, 1 March 1998
• Defense Information Infrastructure (DII) Common Operating Environment (COE) Integration and Runtime Specification (I&RTS), Version 3.0, July 1997
• USIGS Conceptual Data Model, 25 June 1998
• Department of Defense Joint Technical Architecture, Version 2.0, May 1998