Bidders Library Interoperability Test and Evaluation - JITC Notional Guide for Action Officers.pdf

1.1.

DEFENSE INFORMATION SYSTEMS AGENCY

JOINT INTEROPERABILITY TEST COMMAND

FORT HUACHUCA, ARIZONA

NOTIONAL GUIDE

FOR

ACTION OFFICERS

INTEROPERABILITY

REQUIREMENTS REVIEW

VERSION 1.0

AUGUST 2019

NOTIONAL GUIDE FOR ACTION OFFICERS

INTEROPERABILITY REQUIREMENTS REVIEW

AUGUST 2019

Submitted by: Alan R. Rieffer Chief, Strategy and Policy Branch

Approved by: ______________________________

AMANOLLAH ADELI

Acting Chief, Strategy, Plans, and Engineering

Prepared Under the Direction of:

Frank G. Diaz Joint Interoperability Test Command

Fort Huachuca, Arizona

This page intentionally left blank.

NOTIONAL GUIDE FOR ACTION OFFICERS 1

INTEROPERABILITY REQUIREMENTS REVIEW 2

1. Introduction 5

2. Interoperability Requirements Review Process 6

3. Interoperability Requirements Review Checklist Overview 7

4. Section A: NR KPP Section Checklist 8

5. Section B: Required Architecture Section Checklist 9

6. Section C: Conditional Architecture Section Checklist 10

1. Introduction 12

The Interoperability Requirements Review is a standardized approach to 14 requirements and integrated architecture analysis. The review facilitates evaluation 15 planning and risk reduction to the Program Management Office (PMO)/Sponsor and the 16 Joint Interoperability Test Command (JITC). The Strategy and Policy Branch (JT4A) 17 assigns the applicable Test Division to conduct a Requirements Review when JITC 18 receives a new set of requirements. 19

A JITC Action Officer (AO) can receive new system requirements through the 21

Global Information Grid Technical Guidance-Federation (GTG-F) Interoperability and 22 Supportability Assessment Module (IAM), Knowledge Management/Decision Support 23 (KM/DS), and/or directly from a PMO. 24

The focus of the Interoperability Requirements Review Checklist (Sections A, B, 26 and C) is to support AOs when JITC receives a tasking to review requirements. 27 Requirements can be in various formats and levels of detail depending on the stage of 28 review. Information Support Plans (ISPs) are located on the GTG-F IAM at an Initial, 29 Update, Revision, or Final Review stage. Joint Capabilities Integration and 30 Development System (JCIDS) type documents (Interim Capabilities Document (ICD), 31 Information System (IS)-ICD, Capabilities Development Document (CDD), and IS-CDD 32 are on the KM/DS at Document Review (stage1) or Functional Capabilities Board (FCB) 33 Draft Review (final stage). Other requirements that can also be in various formats are 34 Architecture Viewpoints and an Net-Ready Key Performance Parameter (NR KPP) table 35 (draft of final stage). 36

This Notional Guide (NG) is written in a conversational style with the JITC 38 workforce in mind (JITC Test Divisions, AO or test officers, hereafter referred to as AOs, 39 "you" or "your"). Program Management Office terms “PMO” and “PMO/Sponsor” are 40 used interchangeably in this guide. 41

Additionally, this NG uses special text boxes to present helpful information. The 43 special text boxes are annotated with the following icons: 44

For Your Information Reviewing 46

1.1 Purpose 1

The purpose of this NG is to provide a standardized process to conduct an 3 Interoperability Requirements Review of the PMO/Sponsor’s requirements document, 4 NR KPP, and Architecture Viewpoints. 5

It also: 7

Focuses AOs review efforts on information needed for interoperability Test, 9 Evaluation and Certification (TE&C) 10

Provides feedback on: 11 o Draft/Final requirements document 12 o Certified/Draft NR KPP 13 o Approved/Draft Architecture Viewpoints 14

Maps requirements to interoperability evaluation framework 15

1.2 Applicability 17

This NG is applicable when the AO is conducting an Interoperability 19 Requirements Review and generating a Comment Resolution Matrix (CRM) based on 20 the review. 21

2. Interoperability Requirements Review Process: Interoperability & 23 Supportability Assessment Module vs Knowledge Management/Decision Support 24

JT4A will manage all formal Interoperability Requirements Reviews and 26 coordinate with the respective Lead Division and AO to document comments to the 27 GTG-F IAM or KM/DS tools, as applicable. JT4A will designate an Executive Agent, 28 Lead Assessor or Assessor Point of Contact (POC), and alternates to be responsible for 29 the following: 30

Identify the Division responsible to review requirements 32

Provide technical assistance and coordinate publication using the IAM or 33 KM/DS, as applicable 34

2.1 Activities Involved with the Interoperability Requirements Review Process 37

The IAM and KM/DS use the same Interoperability Requirements Review 39 checklist; however, the way the two are tasked are slightly different. The following are 40 the steps used to task the review for each tool. 41

For the IAM: 43

Assessors and Lead Assessors require an IAM account. 44

The IAM sends tasking email to all Assessors (ignore these emails). AOs will 1 receive an email from their respective Division Chief, Branch Chief, or the 2 Document Review Team when they are the designated Assessor. 3

The AO must enter the comments into the IAM in the proper section, and 4 obtain approval from the Lead Assessor and have the comments officially 5 published into the IAM prior to the suspense date. If Lead Assessor does not 6 publish comments prior to the comment suspense date, IAM will default to 7 publishing any comments at the close of business (Greenwich Mean-Time) on 8 the comment suspense date. Guidance on using the comment and 9 adjudication functions in the IAM is located at 10 https://gtg.csd.disa.mil/uam/support/userDocument/list. Input only 11 UNCLASSIFIED comments to IAM. 12

For any JITC critical comments (see sections 2.2, 2.3, and 2.4),especially 16 critical comments, even those generated by multiple substantive comments, 17 the comments must be discussed with the original author (document sponsor) 18 and documented (name, phone number, and date contacted). For final 19 reviews, any JITC comments or non-concurs must be discussed with the 20 original author. 21

Assessors should review previous comments to ensure their current 22 submissions are consistent with earlier JITC and other organization’s 23 comments. 24

IAM will generate notifications when PMO/Sponsor adjudicates comments; 25 JITC must accept or reject proposed adjudications. 26

Assessors will update the System Tracking Program (STP) as needed to 27 keep the entry up-to-date, which will support accurate metrics and reporting. 28

The ISP may go through several assessments before final concurrence. 29

Figure 1 depicts the IAM workflow process. 31

For Your Information

Classified reviews will be in accordance with (IAW) the “Classified Intelligence and

Security Assessment Process User’s Guide” with instructions from JT4A (provided in the tasking e-mail from JT4A).

Figure 1. IAM Workflow Process 2

Reviewing

JITC internal review process is the same for both a full or partial ISP review. A partial

ISP review will only look at the NR KPP and architecture products.

For KM/DS: 6

Reviewers require a KM/DS and SECRET Internet Protocol Router Network 8 (SIPRNet) account (KM/DS resides on SIPRNet). 9

Appropriate security measures for the SIPRNet must be followed. 10

For Your Information

Business systems (as under Department of Defense Instruction (DoDI) 5000.75, “Business Systems Requirement and Acquisition”, February 2, 2017, Change 1, August

31, 2018) can avoid ISPs; however, the current Department of Defense (DoD) process still requires the PMO to submit a "shell" ISP through GTG-F IAM. The 13 architecture products and NR KPP are still required, as outlined in JITC Interoperability Process

Guide (IPG), Version 2.0, 23 March 2015, Incorporating Change 1, 30 October 2018.

The JITC Document Review Team will download the document to be 1 assessed (and any supporting documentation) into a shared team folder that 2 is identified in Note 1 of tasking email from JT4A (Note: Remote users will 3 have different procedures because of access restrictions). 4

All comments (see sections 2.2, 2.3, and 2.4) must be entered into the 5 provided CRM template in the KM/DS (available in the SIPRNet team folder). 6 A different or modified CRM will not upload into the KM/DS and the comments 7 will have to be entered manually. 8

AOs should review previous comments to ensure their current submissions 9 are consistent with earlier JITC and other organization’s comments. To non-10 concur because of multiple substantive comments, include a critical comment 11 that says so. KM/DS automatically sets the “concur with comments/non-12 concur” field based on the highest criticality comment received. Any 13 classified comments must include derived-from and declassification 14 statements. 15

For any JITC comments, especially critical comments, even those generated 16 by multiple substantive comments, the comments must be discussed with the 17 original author (document sponsor) and documented (name, phone number, 18 and date contacted). For Final/ FCB Draft reviews, any JITC comments, 19 especially non-concurs must be discussed with the original author. The 20 purpose is to ensure comments from initial staffing have been adjudicated to 21 the satisfaction of the commenter. Therefore, the commenting should be 22 limited to only the proposed changes. This phase of staffing is NOT intended 23 to solicit new comments. 24

Reviewers will update the STP as needed to keep the entry up-to-date, which 25 will support accurate metrics and reporting. 26

Send comments via SIPRNet email to the individuals indicated in the JT4A 27 tasking email under paragraph 3 of GENERAL INSTRUCTIONS, providing: 28 o Recommendation (Concur, Concur w/Comments, Non-Concur) 29 o Reviewer 30 o Division/Portfolio Chief concurrence 31 o Notes: e.g., STP entry has been made or updated; document sponsor 32 contacted for non-concur 33

Once the comments and recommendation are approved, notify the Document 34 Review Team via Non-secure Internet Protocol Router Network (NIPRNet) 35 email at disa.huachuca.jitc.mbx.doc-review@mail.mil and they will upload the 36 CRM and recommendation into KM/DS. JS J-8 uses a single review cycle for 37 JCIDS documents (means that KM/DS maintains same Document Control 38 identification number 20000XXXX for Initial/Document review and Final/FCB 39 Draft review. 40

Figure 2 depicts the KM/DS workflow process. 2

Figure 2. KM/DS Workflow Process 5

Reviewing

The J-8 Gatekeeper normally staffs requirements with the following statement:

"Critical comments submitted to KM/DS in response to document staffing are expected to be signed out at the General Officer (GO)/Flag Officer (FO)/Senior Executive Service (SES)-level. Submit GO/FO/SES approver information as well as the AO with who comment adjudication can be worked. Commenters should expect the sponsors to reject comments that do not include GO/FO/SES approval details".

AOs are encouraged to provide critical comments when warranted (see sections 2.2, 2.3, and 2.4) in their CRM, ensuring they are properly coordinated with document sponsor and senior leadership. JITC JT4A can assist with GO/FO/SES coordination if determined to be necessary.

For Your Information

KM/DS or JCIDS reviews will typically be one of two types: Document review (initial or

4.0 commenting stage in KM/DS), or FCB Draft (final or 8.0 commenting stage in

KM/DS). 4.0 reviews can be from 20-30 days while 8.0 reviews can be from 7-14 days.

2.2 Reviewing and Documenting Discrepancies 1

Using the checklist (described in Section 3) during your review will help identify 3 gaps and discrepancies between the NR KPP and the required Architecture Viewpoints. 4 While it is important to identify these discrepancies, it is equally important to document 5 them as well. Ensure your comments to the discrepancies are detailed, provide a 6 recommendation and a rationale. Too little information can give the owning 7 organization the impression the comments do not support the criticality level (indicator) 8 and will disrupt the coordination and adjudication process. The goal is to identify all 9 critical comments early, so they can be resolved before the final review stages; critical 10 comments provided during a final review can affect a Milestone (MS) C fielding 11 decision. 12

2.3 Assigning Criticality 15

Assigning a level of criticality to comments will assist stakeholders in making 17 informed decisions on what needs to be updated/changed in the requirements in order 18 to conduct an interoperability TE&C. Keep in mind JITC clearly defines what 19 substantiates each level of criticality in the JITC IPG. 20

The following describes each level of comment criticality: 22

Critical Comment – Critical comments must identify violations of law or 24 contradictions of Executive Branch or DoD policy (i.e., unnecessary risks to 25 safety, life, limb, or DoD material; waste or abuse of DoD appropriations; or 26 imposition of an unreasonable burden on a Component's resources; an 27 information-related issue that would prevent the program's ability to provide a 28 required operational/functional capability; or missing integrated architectural 29

For Your Information

Comments made in MS A and early in MS B will not be as critical as they would be in late MS B and MS C. Reference DoDI 5000.02, “Operation of the Defense Acquisition System”, January 7, 2015, Incorporating Change 3, August 10, 2017.

During these early stage Milestones (A and B), there is plenty of time to fix/address any gaps and discrepancies before they impact interoperability TE&C and it also allows the AO an opportunity to coordinate with JS/PMO/Sponsor.

For all stages of review, reviewers/assessors must assign their comments a criticality level (Critical, Substantive, or Administrative) according to the “Interoperability Requirements Review comment criticality”. Every comment must also:

1) Identify the deficiency

2) Provide a specific recommendation

3) Provide a rationale for the comment/recommendation.

product content needed to provide or validate measurable/testable 1 requirements). Any critical comments result in an automatic non-concur. 2

Substantive Comment – A substantive comment identifies unnecessary, 3 incorrect, misleading, confusing, or inconsistent information with other sections; 4 disagreement with the proposed responsibilities, requirements, or procedures; or 5 an issue that would significantly impact the program's ability to provide a required 6 operational and/or functional capability. One substantive comment is usually not 7 sufficient justification for a non-concur; however, multiple substantive comments 8 may be grounds for a non-concur. 9

Administrative Comment – An administrative comment concerns non-substantive 10 aspects, such as dates of references, format, typographical, and grammar errors. 11 Administrative comments will never warrant a non-concur. 12

Reviewing

During the Interoperability Requirements Review process, AOs typically assign a criticality level higher than what is required because AOs want the PMO/Sponsor to address a particular gap/discrepancy. Do not get caught up in this practice. Stick to the guidelines depicted in this paragraph.

Ensure compliance with the JITC IPG when assigning a comment as critical because it can impact staffing to the extent that a PMO must adjudicate all critical comments prior to proceeding with further acquisition development

2.4 Coordination and Adjudication 15

Prior to submitting your comments in the IAM or KM/DS, you will want to 17 coordinate your findings with the JS and the PMO/Sponsor, especially critical comments 18 or a significant amount of substantive comments leading to a “Non-Concur” of the 19 requirements. 20

Consider the following: 22

Find out who your JS rep is and let them know you are getting ready to 24 conduct a Requirements Document Review 25

For Your Information

There are four recommendations to comments. They are:

1. Concur (agree)

2. Concur with Comments (the issues are less than critical to JITC interoperability testing requirements)

3. Non-Concur (disagree)

4. Not Applicable (JITC interoperability testing is not required)

(It is important to contact JS to open lines of communication early. Any 1 issues with the NR KPP should be discussed with the JS ONLY, not the 2 PMO/Sponsor.) 3

Find out who your POC will be within the PMO/Sponsor to discuss issues with 4 the Architecture Viewpoints 5 (You should share any critical issues with the PMO/Sponsor as soon as 6 possible. If issues are identified early, it will be easier to resolve them.) 7

Ensure you have the Notional Guide to AOs – Architectures TE&C v2.1 available 9 prior to starting your review. The NG will provide you with the necessary information 10 needed when providing comments and rationale to the gaps and discrepancies you 11 identify during your review and the impact they will have on interoperability TE&C. 12

Reviewing

IAW DoDI 8330.01, “During a review, the owning DoD Component must staff the ISP to the appropriate entities for comment using the GTG-F, then work with the PM to adjudicate the comments. The PM adjudicates critical comment by actively engaging with the organization and person who made the comment. The DoD Component must review and approve the ISP each time it is submitted. For critical comments that cannot be resolved, the issue is elevated through the owning DoD component head’s designated representative for the DoD CIO’s resolution. The PM must brief critical risks and issues identified through ISP review to Integrated Product Teams as appropriate. All critical comments must be fully adjudicated before issuing the final approval of the ISP of record”. If you are certifying to other than an ISP, it goes for that document as well.

3. Interoperability Requirements Review Checklist Overview 15

The Interoperability Requirements Review Checklist assists the AO in conducting 17 a formal Interoperability Requirements Review and helps the AO extract test 18 requirements from the JS Certified NR KPP and approved Architecture Viewpoints. The 19 checklist is also the basis for most comments. 20

3.1 Interoperability Requirements Review Checklist Instructions 22

There are a couple of things you need to know before you start using the 24 checklist: 25

1. Is there a draft/certified NR KPP? 27

2. At minimum, are all 13 required viewpoints available for review? 28

If you answered yes to both of these questions you are ready to get started. Begin 30 by ensuring you have a blank checklist, the Notional Guide to AOs – Architectures 31 TE&C v2.1, and a blank CRM. 32 http://jitc.fhu.disa.mil/projects/isgsite/pubs.aspx http://jitc.fhu.disa.mil/projects/isgsite/pubs.aspx http://jitc.fhu.disa.mil/projects/isgsite/pubs.aspx

3.2 Interoperability Requirements Review Rules 1

Observe the following rules for a comprehensive Interoperability Requirements 3 Review: 4

Treat each review as the only opportunity to improve the requirements 5

Use the checklist, focusing on requirements testability, traceability, and 6 completeness based on the joint interoperability evaluation framework 7

Assess traceability of requirements in the NR KPP and associated 8 Architecture Viewpoints. A requirements traceability matrix (e.g., Integrated 9 Architecture Traceability Matrix (IATM)) is useful for this assessment 10

Administrative comments should not be included unless necessary to 11 understand the requirements 12

Every comment must be complete, unambiguous, and specific 13

Every comment must describe exactly what the problem is, how to correct it, 14 and why the correction is needed 15

Recommendation must agree with the comment(s) 16

Refer to the “Joint Interoperability Evaluation Guidebook” for checklists and 17 IATM guidance 18

3.3 Comment Resolution Matrix Instructions 20

Every field in the CRM is required. You will want to provide as much detail, in the 22 comment, recommendation, and rationale fields, as possible so the Assessor/Lead 23 Assessor can make an informed decision (criticality level) during their review of the 24 requirements. Remember to use the criticality definitions outlined in section 2.3 in this 25 guide, when assigning a criticality level to your comments. 26

Table 1 below is a sample CRM that can be used during your review of 28 requirements in the IAM (this IAM CRM format will help Assessors with the requirement 29 to input comments directly into IAM, as a separate CRM is not submitted). Table 2 is a 30 sample CRM used during your review in KM/DS and submitted into KM/DS. 31

Table 1. Sample CRM Template for IAM 33

Criticality (C, S, A) Page # Paragraph # Line # Classification (U, C, S, F)

C 1 1 1 U

Reviewer: IC Freely

Reviewer Org: JITC

Reviewer Email: ic.freely.civ@mail.mil

Reviewer Phone: 520-538-1111 or DSN 879-1111

Comment: SV-4 lists system functions but does not show data flows.

Recommendation: Add more detail to show data flows between system functions/systems.

Rationale:

The SV-4 should develop a clear description of the necessary data flows that are input (consumed) by and output (produced) by each system. The data flows identify, more accurately; the requirements needed to evaluate/certify the system.

(Legend on next page) 35 https://disa.deps.mil/org/JT4/JT4%20Public%20Shared%20Document%20Library/JT4A/Joint%20IOP%20Evaluation%20Guidebook%20Final-Signed.pdf mailto:ic.freely.civ@mail.mil

LEGEND

A Administrative IAM Interoperability and Supportability Assessment Module C Confidential (under Classification JITC Joint Interoperability Test Command C Critical (under Criticality) Org Organization CRM Comment Resolution Matrix S Secret (under Classification) DSN Defense Switched Network S Substantive (under Criticality) Email Electronic Mail SV System View F For Official Use Only U Unclassified

Table 2. Sample CRM Template for KM/DS 3

Org/Reviewer/ Email/Phone

Page Para Line Class

(U,S,C) Type

(A,S,C) Recommended

Change Rationale Comment

JITC/Joe Fresh joe.fresh.civ@mail.mil/ 538-1111

58 3 1126 S C Provide OV-3

OV-3

Supports NR

KPP

(Attribute 3)

OV-3 depicts information exchanges between nodes.

NOTE: Do not attempt to modify this template. Doing so may cause the comment resolution matrix upload to fail.

LEGEND:

A Administrative NR KPP Net Ready Key Performance Parameter C Confidential (under Class)/Critical (under Type) Org Organization CRM Comment Resolution Matrix OV Operational View Email Electronic mail Para Paragraph

JITC Joint Interoperability Test Command S Secret (under Class) / Substantive (under Type)

KM/DS Knowledge Management/Decision Support U Unclassified

Reviewing

Do not cut/paste from the ‘Guidance’ in the checklist while you are filling in the CRM.

While the checklist provides guidance for each question it does not provide you with the level of detail required to make a criticality determination. It is important to have the Notional Guide for AOs Architecture TE&C v2.1, which provides a clear understanding of what a particular Architecture Viewpoint should provide for an interoperability TE&C.

Now that you have completed your CRM, it’s time for the coordination and 7 adjudication of your comments. 8 Coordination: 10

Comments related to the NR KPP (i.e., gaps/discrepancies) should be 12 coordinated with your JS representative. Remember, the JS is responsible 13 for the NR KPP, not the PMO/Sponsor. 14

Comments related to the Architecture Viewpoints should be coordinated and 15 discussed with the PMO/Sponsor. 16

All Critical comments should be coordinated with both the JS and the 17 PMO/Sponsor. By communicating any critical issues early you may be able 18 to resolve them prior to submitting your comments. 19 mailto:joe.fresh.civ@mail.mil/ https://jit.fhu.disa.mil/isg/download/Notional_Guide_-_Architectures_for_TEC_v2.1_Final.pdf

Adjudication: 2

Critical comments that will lead to a ‘Non-Concur’ should be adjudicated with 4 your leadership prior to submission. This goes for a large amount of 5 substantive comments as well. 6

Ensure the PMO/Sponsor has the necessary information when they begin 7 their adjudication process (i.e., be prepared to clarify anything the 8 PMO/Sponsor doesn’t understand about your comments, recommendations, 9 and rationale). 10

3.4 Checklist Template 13

The following checklist template will be used for both the IAM and KM/DS. The 15 checklist template is divided into three sections: 16

Section A provides questions for the review of the NR KPP 18

Section B provides questions for the review of the “Required” Architecture 19 Viewpoints 20

Section C provides questions for the review of the “Conditional” Architecture 21 Viewpoints 22

The checklist legends can be found at the end of each section. 24

For Your Information

The program may not consider comments posted after the suspense date.

For Your Information

“Required” viewpoints represent mandatory architecture information to evaluate the interoperability of a system.

“Conditional” viewpoints are mandatory under certain conditions (i.e., when a system is sharing data and services).

Section A: NR KPP Checklist

X. Requirement X.X Potential Issue(s)

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD ISP

1. NR KPP Overview Discuss any issues with the NR KPP with your JS representative as soon as possible. Do not discuss these issues with the PMO/Sponsor.

1.1. Attribute 1 Support Military Operations:

Does the NR KPP include an operational mission statement?

Operational Missions can typically be depicted in the AV-1, OV-5a/b, OV-6cs, SV-7, and within the document under review. Ensure traceability of operational mission(s) to supporting architectures/document.

1.2. Attribute 1 Support Military Operations:

Does the NR KPP include threshold criteria for MOEs and MOPs?

Is the criteria measurement a value that can be measured in accordance with interoperability factors (timeliness, accuracy, completeness, periodicity, throughput, size, etc.)?

1.3. Attribute 1 Support Military Operations:

Does the NR KPP use a standardized method to document the missions, e.g. JMETL, JMT, or UJTL?

Is there consistent numbering or labeling format between NR KPP, DoDAF viewpoints, and requirements documents?

1.4. Attribute 1 Support Military Operations:

Does the NR KPP include the conditions under which the mission will be performed?

This can drive resources and funding when designing test events. Crosswalk network requirements and external data/services that would drive the DSS.

1.5. Attribute 1 Support Military Operations:

Does the NR KPP include a MOE that is used to determine mission success?

The operational “so what”: can a user accomplish the systems required mission?

1.6. Attribute 1 Support Military Operation: Does

the NR KPP identify the ‘stressing thread’? (For IT that supports multiple missions)

A mission thread is defined as a specific sequence of tasks to accomplish a mission in a given scenario. A stressing thread should be the mission thread that creates the most demand on the system under test. OV-6c supports mission thread depictions.

1.7. Attribute 2 Enter and Be Managed on the

Network: Are Networks depicted?

Network systems can typically be depicted in SV-1, SV-2, SV-6, SV-7, and within the document under review.

1.8. Attribute 2 Enter and Be Managed on the

Network: Does Attribute 2 trace to supporting architectures/document?

Review the SV-1, SV-2, SV-6, SV-7, and ISP to determine if the NR KPP Network(s) requirement(s) are traceable to the architectural products/document.

1.9. Attribute 3 Exchange Information: Are

Information Exchanges depicted?

Information Exchanges can typically be depicted in SV-6, OV-3, and within the document under review.

Section A: NR KPP Checklist (continued)

For Your Information

Critical comments for the NR KPP should only be made when:

1. Comments have been socialized with the JS

2. The JS disagrees or chooses not to make the comments themselves

3. The issues with the NR KPP affect testability, traceability, and overall evaluation of the system

1.10. Attribute 3 Exchange Information: Does

Attribute 3 identify the Effective Information Exchanges details such as exchange identifiers, information exchange elements, measures, criteria, and conditions?

Review the SV-6, OV-3, and ISP to determine if the NR KPP requirements are traceable to the architectural products/document.

1.11. Attribute 3 Exchange Information: Do the

Information Exchanges relate to the Attribute 1 tasks?

Review the OV-3, OV-5, SV-6, and SV-7 for common terminology and numbering for tasks and exchanges.

NOTE: JITC will not normally evaluate mission success. However, JITC will evaluate and report on the status of information exchanges that support the mission(s). Your review should verify that the missions are present and appear to be correct, to the best of your ability.

LEGEND:

AV All Viewpoint ISP Information Support Plan NA Not Applicable CDD Capabilities Development Document JMT Joint Mission Thread NR KPP Net Ready Key Performance Parameter DSS Data and Services Strategy JMETL Joint Mission Essential Task List OV Operational Viewpoint DoDAF Department of Defense Architecture Framework JS Joint Staff PMO Program Management Office ICD Interim Capabilities Document MOE Measures of Effectiveness SV System Viewpoint IS Information System MOP Measures of Performance UJTL Universal Joint Task List

Section B: Required Architecture Checklist

2. AV-1: Overview and Summary Information

2.1. the AV-1 present?

JITC uses the AV-1 to understand the scope of the architecture and its relationship to other architectures and provide a context for the other models.

2.2. Does the AV-1 provide accurate information?

2.3. Does the AV-1 link all other viewpoints?

AV-1 looks at “why” (motivation) and is associated with meta-Viewpoint group for Rules and Goals, as well as a navigation aid to the other viewpoints that have been created.

2.4. Does the content in the AV-1 describe the

concepts in the pictorial representation of the OV-1?

The AV-1 and a corresponding graphic in the form of an OV-1 serve as an executive summary of the Architectural Description/Identification. This is not a one-to-one relationship.

3. AV-2: Integrated Dictionary

3.1. Is the AV-2 present?

The AV-2 provides doctrine, organization, training, material, leadership and education.

3.2. Does the AV-2 provide text definitions for each

hierarchy regarding data and source elements?

The AV-2 shows elements from the DM2 that have been described in the Architectural Description and new elements (i.e., not in the DM2) that have been introduced by the Architectural Description.

3.3. Does the AV-2 link to all other viewpoints?

The AV-2 provides an understanding of the scope for the other architecture products, its relationship to the other products and provides a context to the other models.

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

ISP

Section B: Required Architecture Checklist (continued)

4. OV-1: High-Level Operational Concept Graphic

4.1. Is the OV-1 present?

OV-1 provides a graphical depiction of what the architecture is about and an idea of the performers and operations involved. It is intended for presentation to high-level decision-makers. Optimally, supporting textual narrative communicates missions and users reflected in the graphics.

4.2. Does the mission (or missions) depicted in the

OV-1(s) agree with the mission(s) contained in the

NR KPP?

4.3. Are the organizations, organization types, and/or human roles traceable to the OV-2?

The OV-1's objects (e.g., organizations and human roles) should trace to the OV-2's nodes.

Successful traceability will result in more accurate interoperability testing and certification.

4.4. Do relationships trace to needlines in the OV-

2?

The OV-1's object relationships (i.e., between organizations and between organizations and human roles) must trace to the OV-2's needlines. The OV-2's needlines provide the OV-1's relationships with specific identification and attributes, which will result in more focused interoperability testing and certification.

4.5. Does the OV-1 trace to the relationships

described in the OV-4?

Elements in the OV-1 must be traceable to the organizations and/or roles and their relationships described in the OV-4.

4.6. Does the OV-1 trace to the elements in the

OV-5a/b?

Elements in the OV-1 representing activities, their Inputs and Outputs, and Controls and Mechanisms must be traceable to elements in the OV-5a and b.

4.7. Does the OV-1 relate to the system, system

resource flow and system interfaces depicted in the

SV-1?

The depiction of systems may be included to convey the concept graphically to the customer of the OV Viewpoint. Elements in the OV-1 for a solution architecture must relate to the system, system resource flow, and system interfaces depicted in the SV-1.

4.8. Does the OV-1 relate to the system and

communications connection depicted in the SV-2?

Elements in the OV-1 for a solution architecture must relate to the system and communications connections depicted in the SV-2.

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

5. OV-2: Operational Resource Flow Description

5.1. Is the OV-2 present?

The OV-2 depicts Operational Resource Flows (Needlines) that indicate a need to exchange resources (information, funding, people, or materiel) between Performers, Locations, Organizations, and Activities, etc. These Performers, Locations, Organizations, and Activities, etc.

may be external to the architecture’s scope to show the required interactions with external entities.

5.2. Does the OV-2 include unique

needline(s)/node ID(s)?

5.3. Does the OV-2 provide details on associating

an organization type to a node, if needed to understand the facilities/system nodes?

OV-2 can also group organizational structure elements from an OV-4, if provided.

5.4. Are the organizations, organization types, human roles and/or needlines traceable to the OV- 1?

The organizations, organization types, human roles and/or needlines shown in various views must trace back to the OV-1.

5.5. Do the OV-2 needlines map to one or more

information exchange in OV-3?

The OV-2's needlines must map to the OV-3's information exchanges.

5.6. Do the OV-2 performers trace to the inputs, outputs and controls in the OV-5b?

Performers in the OV-2 may perform Operational Activities described in the OV-5b. In addition, resource flows in the OV-2 may be inputs, outputs, and controls in the OV-5b.

5.7. Do the operational nodes in the OV-2 map to

lifelines in the OV-6c?

The OV-2's operational nodes must map to the OV-6c's lifelines. Depicts the users in the OV-6c sequences.

5.8. Are operational nodes supported by one or

more systems in SV-1 indicating that the operational node owns/uses the system?

Each operational node must be supported by one or more systems shown in the SV-1. This will provide completeness of operational node/system relationships and support interoperability testing and certification.

5.9. Do needlines in the OV-2 map to one or more

interfaces in the SV-1?

The system needlines must map to one or more interfaces in the SV-1. This will provide traceability of needlines that will support interoperability testing and certification.

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

6. OV-3: Operational Resource Flow Matrix

6.1. Is the OV-3 present?

The OV-3 depicts information exchanges between nodes and the relevant attributes of those exchanges Each system information exchange must be associated with at least a pair of nodes and corresponding organizations/users, a needline, and usually, though not always, an interface description (per the SV-1). The OV-3 supports NR KPP Attribute 3.

6.2. Do all information exchanges map to a

needline in the OV-2?

6.3. Do OV-3 resource flows map to one or more

resource flows in the OV-5a/b?

Source and Destination Activities in the OV-3 must align with Activities listed in the OV-5a.

Resource Flows in the OV-3 map to one or more Resource Flows (Input, Output, or Control) in the OV-5b, if the OV-5b decomposes to a level that permits such a mapping.

6.4. Do OV-3 triggering events map to OV-6c

events?

OV-3 triggering events must map to OV-6c events. This will provide the correct sequence of events occurring between operational users.

6.5. Does the OV-3 reference data relate to one or

more data entities in the DIV-2?

Reference Data in the OV-3 is related to one or more Data Entities in the DIV-2. Any change to this attribute in the OV-3 must be reflected in the DIV-2.

6.6. Do the automated OV-3 information

exchanges map to one or more system data exchanges in the SV-6?

The Operational Resource Flow Identifier must appear as a unique identifier in the OV-3 and must be referenced in the SV-6 as a table field to provide a linkage between the OV-2, OV-3, and SV-6 for traceability. The system data exchanges are the unique identifiers for each row entry in the SV-6 table.

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

7. OV-5b: Operational Activity Model

7.1. Is the OV-5b present?

The OV-5b describes the operations that are normally conducted in the course of achieving a mission or a business capability. It describes capabilities, operational activities (or tasks), input, and output (I/O) flows between activities, and I/O flows to/from activities that are outside the scope of the architecture. The OV-5b supports NR KPP Attribute 1.

7.2. Does the OV-5b include required operational

nodes/activities?

The OV-5b must clearly map operational nodes/activities in order to provide consistency in interoperability testing.

7.3. Are the Producing and Consuming performers

and Information Exchanges in the OV-5b depicted as resource flows in the OV-2?

Producing and Consuming Performers and Information Exchanges in the OV-5b are represented as resource flows by the OV-2. Any changes to performers or information exchanges may have to be reflected in the OV-2.

7.4. Are the Producing and Consuming Performers

and Information Exchanges in the OV-5b represented, in great detail, as resource exchange requirements in the OV-3?

Producing and Consuming Performers and Information Exchanges in the OV-5b are represented, in great detail, as resource exchange requirements by the OV-3. Activities described in the OV-5b should be the same as those that are associated with Performers in the OV-3. Producing and Consuming Performers capable of responsibility, i.e., organizations, types of organizations and person roles initiating the resource flow.

7.5. Is the OV-5b linkage to the OV-6c clear? The OV-5b provides a necessary foundation for depicting activity sequencing and timing in OV-6c.

7.6. Can you determine the criticality of the OV-5b

activities?

Critical mission threads and operational information exchanges should be annotated as critical.

7.7. Do the operational activities depicted in the

OV-5b map correctly to the SV-5a?

The OV-5b operational activities must map to the SV-5 operational activities. This will provide consistency in interoperability testing and certification by showing traceability between OV-5b and

SV-5.

7.8. Do the OV-5b Resources map to a

system/service resource flow in the SV-6?

The Resource in the OV-5b maps to a system/service resource flow in the SV-6 and SvcV-6.

Operational Activities in the OV-5b may map to a system/service function listed in the SV-6.

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

8. OV-6c: Event-Trace Description

8.1. Is the OV-6c present?

The OV-6c, sometimes-called sequence diagrams, event scenarios, or timing diagrams, allow the tracing of actions in a scenario or critical sequence of events. At its highest level, the OV-6c depicts organizational strategy aimed at the executive level, while at its lowest, most detailed tactical level, it can be used as the basis of “how to” instructions. It can be used by itself or with the OV-6b (not seen here) to describe the dynamic time-ordered behavior of activities. The OV-6c supports NR KPP Attribute 1.

8.2. Does the OV-6c provide sequence of

operational events?

The OV-6c should define the timing and sequence of messaging events across multiple operational nodes (depicted as swim lanes).

8.3. Does the OV-6c provide timeliness

information?

The OV-6c should identify the warfighter's timeliness requirement from an end-to-end perspective.

Timeliness data may not be ready for a CDD as a final solution may not yet be realized.

8.4. Do OV-6c events map to OV-2 Operational

Resource flows?

The OV-6c elements relate to the Performer and the Resource Flows between them. Any changes to the OV-6c must be reflected in the OV-2. Changes to users in OV-6c must be reflected in OV-2 as well.

8.5. Do the OV-6c events that map to OV-3 depict

Operational Resource Flow Matrix?

The Resource Flow in the OV-3 is represented as Data Objects in the BPMN versions of the OV- 6c.

8.6. Do OV-6c events map to the OV-5b

Operational Activity Model?

A Process, Event or Operational Event depicted in the OV-6c may represent Activities depicted in the OV-5b. In addition, OV-6c sequence and Message Flows represent Resources (Input/Outputs) in the OV-5b. Any changes to OV-6c elements must be reflected in the OV-5b.

8.7. Does the OV-6c reflect any Data Elements

related to the DIV-2 Logical Data Model?

Each OV-6c Data Object is related to one or more Data Elements defined in a metadata schema.

Metadata schemas should be registered in the Metadata Registry in the DSE, or a registry federated with DSE.

NOTE: The DSE is currently not available, however, it is still in DoDI 8320.02. Each service component is responsible for providing a location for metadata.

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

9. SV-1: Systems Interface Description

9.1. Is the SV-1 present?

Only for

IS ICD

The SV-1 addresses the composition and interaction of Systems and should reflect the networks involved. Networks in the SV-1 should trace to Attribute 2 of the NR KPP. For DoDAF v2.02 c1, the SV-1 incorporates the human elements as types of Performers - Organizations and Personnel Types. The SV-1 links together the operational and systems architecture models by depicting how Resources are structured and interact to realize the logical architecture specified in an OV-2 Operational Resource Flow Description. A SV-1 may represent the realization of a requirement specified in an OV-2 Operational Resource Flow Description (i.e., in a "To-Be" architecture), and so there may be many alternative SV models that could realize the operational requirement.

Alternatively, in an "As-Is" architecture, the OV-2 Operational Resource Flow Description may simply be a simplified, logical representation of the SV-1 to allow communication of key Resource Flows to non-technical stakeholders. The SV-1 supports NR KPP Attribute 2.

9.2. Does the SV-1 trace to the OV-2?

The SV-1 Viewpoint links Operational and Systems Viewpoints by depicting how resources are structured and how they interact to understand their logical flow as specified in the OV-2 (Operational Resource Flow Description). A single OV-2 operational needline may translate to multiple interfaces and System Resource Flows.

9.3. Are SV-1 interfaces implemented by SV-2

communications link(s) or communications network(s)?

The SV-1 interfaces must be implemented by the SV-2 communications link(s) and/or communication network(s). The SV-2 communications links and/or communications networks details must be consistent with those of the interfacing systems. This will provide consistency in interoperability testing and certification.

9.4. Do the SV-1 systems match SV-5b systems?

The SV-1 systems must match the SV-5b systems. This will provide consistency in interoperability testing and certification.

9.5. Do the SV-1 systems interfaces map to the

SV-6 system data elements?

Linkage between interfaces and communications systems, links, and networks is critical to evaluating the NR KPP. Interfaces and needlines outlined in the SV-1 must by traceable to the SV-6. This will provide consistency in interoperability testing and certification.

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

10. SV-2: Systems Resource Flow Description

10.1. Is the SV-2 present?

CDD

A SV-2 specifies the System Resource Flows between Systems and may also list the protocol stacks used in connections and should reflect the networks involved. Networks in the SV-2 should trace to Attribute 2 of the NR KPP. A SV-2 DoDAF-described Model is used to give a precise specification of a connection between Systems. This may be an existing connection, or a specification for a connection that is to be made. A SV-2 comprises Systems, their ports, and the Resource Flows between those ports. The SV-2 supports NR KPP Attribute 2.

10.2. Can you determine SV-2 interfaces/ interface

criticality?

The SV-2 associates a system node or facility with an operational node. Note: If an SV-1 is not available to depict key interfaces (a key interface is designated as mission critical), then the SV-2 should reflect this detail. This may also be in the SV-6.

10.3. Does the SV-2 provide system node/facility

linkage to an OV-2 operational node and is it correct?

The SV-2 depicts the Performer (Host/Facility) and the Communications Connections that support the logical flow of resources described in the OV-2. Any modification to these SV-2 elements must be reflected in the OV-2. A single needline in the OV-2 may translate into multiple Communication Connections in the SV-2.

10.4. Does the SV-2 provide depiction of data flow

details and/or is the data flow properly associated with interface(s)?

The SV-2 provides detail on paths of data flows. The SV-2 bridges data flows with interfaces and interface criticality.

10.5. Do the SV-2 communications link(s) or

communications network(s) implement the SV-1 interfaces?

The SV-1 interfaces must be implemented by communications links or communications networks shown in the SV-2. This will provide consistency in interoperability testing and certification.

10.6. Are the Protocols in the SV-2 defined in the

StdV-1?

Any protocol referred to in a SV-2 diagram needs to be defined in the StdV-1 Standards Profile.

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

11. SV-5a: Operational Activity to Systems Function Traceability Matrix

11.1. Is the SV-5a present?

The SV-5a provides a matrix that cross flow(s) operational activities against system functions to depict relationship between the two.

11.2. Do the OV-5b operational activities map to

SV-5a operational activities?

Operational activities in the SV-5a are derived from the OV-5.

11.3. Do the SV-5a operational activities match

OV-5b operational activities?

The SV-5a operational activities must match the OV-5 operational activities. This will facilitate more accurate interoperability testing and certification.

11.4. Does SV-5a contain unique system identifiers

that match system identifiers from the SV-1/4?

A unique Identifier assigned to the System. Must match System Identifier from SV-1/4. The Identifier captures the hierarchy structure or the sequence of Systems in the Viewpoint. Name of the system from the SV-1/4.

Required

YES/NO

/NA

Guidance ICD/

IS ICD

CDD/

IS CDD

ISP

12. SV-6: Systems Resource Flow Matrix

12.1. Is the SV-6 present?

The SV-6 must contain data elements and attributes required to develop testing measures for applying criteria of the NR KPP (related to the integrated architecture element) for all three attributes. The SV-6 supports NR KPP Attributes 2 and 3.

12.2. Are all the system data exchange parameters

entered in the SV-6 and do they correlate with the

SV-4?

The SV-4 system data flows must map to the system data elements that make up the system data exchanges in the SV-6. This will provide consistency in interoperability testing and certification.

12.3. Does the SV-6 describe, in tabular format, system data exchanged between systems?

NOTE: One of these tabs must be an interface identifier tracing to the SV-1 (needline) and referenced in the SV-2.

The focus of SV-6 is on how the system data exchange is implemented, in system-specific details covering periodicity, timeliness, throughput, size, information assurance, and security characteristics of the exchange. In addition, the system data elements, their format and media type, accuracy, units of measurement, and system data standard are also described in the matrix.

The SV-6 data exchange description format includes an interface identifier, which should map to one of the interfaces identified in the SV-1, or referenced in the SV-2.

12.3.1. Data Exchange Identifier (SV-6)

Does each SV-6 System Data Exchange Name and Identifier map to an OV-3 Operational Resource Flow Identifier?

The OV-3 automated Operational Resource Flow Identifiers must map to the system data exchange name and identifier (Unique identifier for each SV-6 table entry) that make up the system data exchanges in the SV-6. These include the sending and receiving systems (i.e., show data flow direction), needlines, and organizations/nodes. This will provide consistency in interoperability testing and certification.

12.3.2. Data Description (SV-6)

Do the Data Elements and Identifiers map to OV- 3 Information Element? Are the following elements depicted in the SV-6:

Data Element Name and Identifier

Criticality

Format Type

Media Type

Accuracy

Units of Measurement

System Resource Flow exchanges express the relationship across the three basic architectural data elements of a SV (systems, system functions, and System Resource Flows) and focus on the specific aspects of the System Resource Flow and the system resource content. These aspects of the System Resource Flow exchange can be crucial to the operational mission and are critical to understanding the potential for overhead and constraints introduced by the physical aspects of the implementation such as security policy and communications limitations.

12.4. Are standards reflected in the SV-6 depicted

against system interfaces and are they from the StdV-1?

The SV-6 should have a column for Data Standards and the standards should be reflected in the StdV-1. JITC strongly recommends that the applicable standards for each System Resource Flow be included here. This will simplify JITC's test preparation and the program's development of their StdV-1.

12.5. Do the SV-6 Sending System Names and

Identifiers map to the OV-2 Performer?

Modeling discipline is needed to ensure that the architecture models are coherent. Each system Resource Flow exchange listed in the SV-6 table should be traceable to at least one operational Resource Flow…