PETERSON AIR FORCE BASE COLORADO 80914-4100 14 January 1994



This regulation implements the direction contained in Department of Defense Instruction 5000.2 (DoDI 5000.2) which takes precedence in the event of conflict with this regulation. It implements an operational change approval management process (OCAMP) for the Commander in Chief, North American Aerospace Defense Command (CINCNORAD) and the Commander in Chief, United States Space Command (USCINCSPACE). It applies to HQ NORAD and its responsible agencies and HQ United States Space Command (USSPACECOM) and its component commands.

1. References. See attachment 1.

2. Background:

2.1. USCINCSPACE is assigned responsibility to manage and control the integrity of the Integrated Tactical Warning and Attack Assessment (TW/AA) System, through the Memorandum in the Name of the Chairman, Joint Chiefs of Staff (CJCS) (MCM 172-91), Integrated Tactical Warning and Attack Assessment (TW/AA) System Integrity, 1 Oct 91. USCINCSPACE is responsible to the President and the Secretary of Defense, through the Joint Staff, for the integrity of the Integrated TW/AA System.

2.2. Integrated TW/AA, Air Defense, and Air Sovereignty mission areas are assigned to CINCNORAD. Force Enhancement, Force Application, Space Control, and Space Support mission areas are assigned to USCINCSPACE. The supporting systems of these mission areas are known collectively as the NORAD/USSPACECOM Integrated Command and Control System (NUICCS). NUICCS is a worldwide, multinational, multi-command, multi-mission integrated command and control "system of systems" supporting CINCNORAD/USCINCSPACE.

2.3. In October 1991, the System Integration Office (SIO) was disestablished. All roles and responsibilities of the SIO were transferred to HQ USSPACECOM and component commands, primarily HQ AFSPACECOM. The SIO Integrated TW/AA System Configuration Control System Directive, Volume I, (CCSD Vol I) Policy and Procedures, was transferred to HQ USSPACECOM/J4L as office of primary responsibility.

3. Definitions. See attachment 2.

4. Purpose. This regulation directs the development and implementation of a comprehensive operational change approval management process for the Integrated TW/AA System. It helps ensure coordination, documentation, and enforcement of the coordination and documentation activities. It also applies to other systems or configuration items (CI) of NUICCS when formally designated by USSPACECOM. This regulation, along with component command regulations, replaces CCSD Vol I.

4.1. Operational Change Approval Management Process (OCAMP). The OCAMP applies to the changing of systems supporting NORAD and USSPACECOM missions in an operational environment.

No. of Printed Pages: 24
Approved by: Maj Gen Phillip E. Bracher
Editor: Pam Gatson
Distribution: F;X (See page 6.)
4.2. Application. This regulation applies to NORAD and its responsible agencies and USSPACECOM and its component commands. HQ NORAD and HQ USSPACECOM will establish Memoranda of Agreement (MOA) with commands and agencies as necessary to effect full implementation of this regulation.

4.3. Principles. The following principles guide development of the specific operational change approval and change implementation process:

4.3.1. The operational user through an operations approval board or panel (OAB/P) (see attachment 3) validates/revalidates change requirements to operational systems from inputs provided by participants involved with the system or CI.

4.3.2. The operational user (i.e., OAB/P) prioritizes requirements, selects proposed solution(s) as appropriate, approves the installation schedule, and operationally accepts a system.

4.3.3. The operational user (designated by the OAB/P) verifies requirements and proposed solution(s) at prescribed milestones throughout the design, development, and implementation process.

4.3.4. The process at attachment 4 consolidates change approval and implementation procedures used within the Integrated TW/AA System, the operational integration approval process, the Operational Integration Working Group/Operational Integration Review Board (OIWG/OIRB), and the implementing organizations' guidelines and best practices. The objectives are to avoid duplication of effort, to streamline the total process, and to eliminate procedural delays in implementing required system changes.

4.3.5. The process ensures requirements are validated and proposed solutions approved by all affected organizations (i.e., operational, logistical, and financial for hardware, software, firmware, communications, and documentation) are evaluated as part of the mission integrity process. For operational CIs under contract upgrade or replacement and new systems and CIs, this process supports the staffing and approval of a system and CI installation 18 months before initial operational capability.

5. Operational Change Approval Structure:

5.1. Requirements (i.e., all changes) validation, selecting of proposed solution(s), and installation schedule are the responsibility of the operations community (i.e., the "what & when" of a change), while implementation (i.e., the "how" of an approved change) rests with the implementing organization (e.g., Air Force Materiel Command (AFMC), Army Materiel Command (AMC)). The operational change approval organizational structure is at attachment 3.

5.2. HQ NORAD, USSPACECOM component commands, and USSTRATCOM (for Command Center Processing and Display System (CCPDS)) must establish Operations Approval Panels (OAP) as shown in figure A3.1, and any sub-boards and review boards as deemed necessary. Their respective operational organization must designate the organizational OAP chairperson, also called the Change Control Manager (CCM), secretariat, members, and advisors. This organizational information is provided to the OAB and AFSPACECOM OAP chair.

6. Operational Change Approval Process. Attachment 4 describes the change approval and implementation process which is a blueprint for all operational changes. The process may be tailored to meet specific system requirements. This regulation acknowledges other processes by using this generic OCAMP and a standard change form (SCF) (see figure A5.1) to ensure operator interaction early in and throughout the change management process.

6.1 During initial verification of a requirement or change request, the responsible individual or group (e.g., requirements clearinghouse, operations review or sub-board, oversight review committee) makes an operational impact assessment. Changes not impacting systems defined by this regulation are forwarded to the appropriate validation office for further processing and leave the OCAMP. Changes continuing through the OCAMP may cause the generation of subsequent forms and documents (e.g., communications-computer systems, hardware and software modifications, facility changes) necessary by the components and responsible agencies to fully implement the requirement. For tracking purposes, any subsequent generated document refers to the original SCF by incorporating the SCF number within the new document.

6.2 The OCAMP is not done in isolation. Simultaneous processes can support the validation and implementation decision points when appropriate. The operator's decision can be based on these processes when considering such areas as standards, technical integrity, and integration risks.

7. Operational Change Approval and Implementation Responsibilities:

7.1. HQ NORAD/J3:

7.1.1. Designates Operations Approval Board (OAB) chair/cochair, secretariat, NORAD members, and advisors. Notifies AFSPACECOM OAP chair of the participants.

7.1.2. Approves/disapproves OAB agenda items (i.e., requirements, selected solution(s), and installation schedule) involving missile and atmospheric warning systems (chairs) and effected NORAD missions, but not NORAD systems (cochairs).

7.1.3. Establishes an Atmospheric OAP with the responsibilities in paragraph 7.7. Designates OAP chair, secretariat, members, and advisors. Notifies AFSPACECOM OAP chair of the designated OAP participants.

7.2. HQ NORAD/J6. Modifies existing MOAs or establishes and maintains new MOAs with responsible agencies not under CINCNORAD Operational Control (OPCON) to ensure implementation of OCAMP.


7.3.1. Designates Operations Approval Board (OAB) chair/cochair, secretariat, members, and advisors. Notifies AFSPACECOM OAP chair of the OAB designated participants.

7.3.2. Approves/disapproves OAB agenda items on multi-command requirement issues, proposed solution(s), and installation schedules.

7.3.3. Identifies in a policy letter those operational systems for which this OCAMP applies.


7.4.1. Ensures operational change approval procedures and guidance are adhered to by component commands. Provides guidance as required.

7.4.2. Modifies existing MOAs or establishes and maintains MOAs with organizations not under USCINCSPACE Combatant Command (COCOM) or OPCON (e.g., USSTRATCOM, USEUCOM, USPACOM) as necessary to support implementation of this regulation.

7.4.3. Acts as the OAB secretariat for change approval decisions (see para 4.3.1) by scheduling and presenting OAB agenda items, publishing agendas and minutes, and tracking OAB agenda items.


7.5.1. Establishes procedures and manages the total Integrated TW/AA System change implementation process to include: Format, timeliness, and content criteria for agendas, minutes, board and panel identification. Vertical release process, version content notification (VCN), version labeling, and version installation date. Operational test and evaluation (OT&E) and trial period.

7.5.2. Publishes a consolidated VCN for vertical releases (modifications (mods)) and all version releases (mods and fixes) to Cheyenne Mountain AFB systems (notifies SPJ6C, OAB, other OAPs, other OASBs as appropriate).

7.5.3. Establishes policy, procedures, and maintains a Common Integrated TW/AA Database (CITD) for Standard Change Forms (SCF) (see attachment 5). The CITD supports the OAB and other OAPs. If an automated CITD system is used, the command distributes and shares the data and software.

7.5.4. Maintains operational configuration baseline documentation for Integrated TW/AA Systems and other operational systems covered by future HQ USSPACECOM policy letters and this regulation.

7.5.5. Maintains, reviews, and validates existing and proposed Integrated TW/AA interface control documents (ICD). Ensures compliance of ITW/AA-STD-4000A and other similar guidance. Establishes a point of contact, coordination, and documentation procedures for the ICD program.

7.5.6. Acts as the OAB secretariat for change implementation, installation, and acceptance decisions (see para 4.3.2) by scheduling and presenting OAB agenda items, publishing agendas and minutes, and tracking those OAB agenda items.

7.6. NORAD Responsible Agencies, USSPACECOM Components, and USSTRATCOM:

7.6.1. Ensure oversight of implementing organization's configuration management throughout the system's life cycle. Ensure configuration management documentation (e.g., baseline identification, change control process, status accounting procedures, audit agendas and results, OAP agendas and minutes, regulations, policies) is forwarded to the OAB secretariat as needed. Ensure configuration management procedures are documented and enforced as specified by MIL-STD-973 or relevant implementing command regulations for status accounting, controlling, identifying, and auditing all baseline changes throughout a system's life cycle.

7.6.2. Coordinate new Integrated TW/AA Interface Control Documents (ICD) and changes to existing ICDs with technical participants and AFSPACECOM system-level engineer.

7.7. Operations Approval Board (OAB) and Operations Approval Panel (OAP):

7.7.1. Accept and approve/disapprove requirements and ensure proper change identification.

7.7.2. Evaluate and revalidate a requirement, proposed solution(s), and implementation decision.

7.7.3. Select and document changes for version and vertical releases.

7.7.4. Task responsible organizations to take specific actions necessary to support implementation of operational changes.

7.7.5. Approve installation of a change.

7.7.6. Determine and document operational acceptance.

7.7.7. Act as principle interface for other OAPs and organizations involved with changes.

7.7.8. As part of the coordination process (normally done by the secretariat): Receive, log and maintain status on SCFs forwarded for disposition (assigns universal control number (UCN), mandatory revalidation). Distribute agenda(s) with proposed decision, priority, and version release, collect responses, and publish minutes with decision to higher, collateral and lower boards/panels (coordinate collateral change(s) impacting OAP and vice versa). Provide SCFs to component command, NORAD responsible agencies, or implementing organization for cost and resource estimates, technical analysis, proposed solution(s), risk assessment, recommendation(s), schedule, corollary impacts, and implementation activities.

7.7.9. OAP only: Establishes Operations Approval Sub-boards (OASB) involved with individual subsystems. Note: Lower boards or panels (e.g., OASB, Operations Approval Review Board (OARB)) may be established as deemed necessary to support the above. Identifies the implementing organization responsible for changing the system(s). The implementing organization and OAP will work closely during the change approval process to make necessary assessments on integration and integrity issues that may arise with other systems or programs. Ensures a proposed change to an operational system, whether permanent or temporary, is documented using the Standard Change Form (SCF) and Universal Control Number (UCN) described at attachment 5. Forwards baseline deviation requests which affect another system to other OAPs or OASBs, Integrated TW/AA System-Level Integrator (AFSPACECOM), and USSPACECOM OAB secretariat as an SCF. Unresolved issues are processed according to paragraphs 7.1.2 and 7.3.2. Establishes the mission impact and priority of the changes (e.g., using MIL-STD-973, paragraph, Class I Engineering Change Priorities (emergency, urgent, routine)). The OAP's (and OASB) authorized actions for emergency, urgent, and temporary changes are defined at attachment 6. Notifies AFSPACECOM OAP of systems and CIs for inclusion/deletion in the baseline documentation listing. Forwards an information copy of validated SCFs to other OAPs, OASBs, and AFSPACECOM OAP (see para 7.5.3). Maintains SCF status accounting information as defined by AFSPACECOM's Common Integrated TW/AA Database. Uses the automated CITD system when provided. Documents and distributes a VCN for system unique and corollary changes (list to SPJ6C, other OAPs, OASBs as appropriate). Acknowledges receipt of AFSPACECOM's OAP vertical release VCN and confirms the ability to support implementation. Coordinates among other OAPs and OAP's OASBs to resolve system requirement or operational change implementation issues. Unresolved issues are processed according to paragraphs 7.1.2 and 7.3.2.

8.Baseline Restriction Policy. Baseline restriction (or freeze) is imposed when a change has the potential to increase acquisition or upgrade program cost and duplicate the efforts of the operational and acquisition communities.

8.1. A restriction period begins for an operational system when an interfacing acquisition or upgrade program is within one year of its earliest initial operational capability (IOC). The period continues until after the last IOC for an acquisition or upgrade program that interfaces with the operational system. During this period, operational changes are scrutinized by the OAPs to ensure resources are not wasted by adding a feature or capability provided by the impending acquisition or upgrade program.
8.2. The OAP may establish a baseline freeze exception policy covering operational and supportability requirements, preserving technical integrity, and allowing the acquisition or upgrade programs and operational systems to converge on a previously projected interface. The respective OAP/OASB coordinates with other OAPs/OASBs to resolve issues and if unsuccessful forwards to the next level board (see para 7.1.2 and 7.3.2).

9. Mandatory Revalidation (Sundown Clause). An SCF must be revalidated or canceled prior to its third (3rd) anniversary. If the requirement is determined to remain valid, it is annotated in block 16, remarks, retained in the CITD, and reviewed annually thereafter.

10. Forms Prescribed. NORAD/USSPACECOM Form 10, Standard Change Form. Note: Approved for computer generation.

General, USAF
Commander in Chief

ROBERT F. KOENIG, JR. 6 Attachments
Colonel, USAF 1. References
Director of Information Management 2. Definitions
3. Operational Change
Approval Structure
4. ITW/AA Operational
Change Approval Process
5. Standard Change Form
and Version Control Number
6. Integrated TW/AA SCF
Assessment and Change Types


NAVSPACECOM, Bldg 183, Code N4/6, Dahlgren, VA 22448 2
HQ USSTRATCOM/J3614, 901 SAC Blvd Ste BA3, Offutt AFB NE 68113-6300 1
Joint Staff/J36/STRAT, Washington, DC 20318-4209 2
HQ Strike Command, Royal Air Force, High Wycombe, Buckinghamshire, HP14 4UE, England 1
HQ 11 Group, Royal Air Force, Bentley Priory, Stanmore, Middlesex, HA7 3HH, England 1
HQ USEUCOM/ECJ3, APO AE, 09128-4209 1
HQ USLANTCOM/J3, Norfolk, VA 23511 1
HQ USPACOM/J3, Camp H.M. Smith, HI 96861-4029 1
HQ PACAF/DOQ/SCL, 25 E St, Suite I-232, Hickam AFB, HI 96853-5426 2
HQ AFMC/XRD, 4375 Chidlaw Rd Ste 6, Wright-Patterson AFB, OH 45433-5006 1
HQ ACC/DOY/DRC/SCY, 205 Dodd Blvd, Suite 101, Langley AFB, VA 23665-2789 3
HQ ESC/TNC/TNW, 5 Eglin St, Hanscom AFB, MA, 01730-2121 2
NDHQ/NWSO 5, Maj Gen Pearkes Bldg, Ottawa, Ontario, Canada K1A OKA 1
AIRCOM HQ/SSO TEL/G5 SP ACS, CFB Winnipeg, Westwin, Manitoba, Canada, R3C OTO 2
SM-ALC/LHF (AFMC), 3200 Peacekeeper Way, Ste 4, McClellan AFB, CA 95652-1029 1
SAMC/CN, Los Angeles, CA 90009 1
DISA/DSSO/JNOR, The Pentagon, Wash, DC 20301 2


A1.1. Department of Defense Instruction 5000.2 (DODI), Defense Acquisition Management Policies and Procedures.

A1.2. Department of Defense Standard 2167A (DOD-STD-2167A), Defense Software System Development.

A1.3. Military Standard 490 (MIL-STD-490), Specification Practices.

A1.4. Military Standard 973 (MIL-STD-973), Configuration Management.

A1.5. Joint Staff Memorandum MCM-172-91, Integrated TW/AA System Integrity, 1 October 1991.

A1.6. USSPACECOM Implementation Plan for the Restructure of the Integrated TW/AA System Executive Management and Transfer of SIO Functions (USSPACECOM IPLAN 1-91), 16 October 1991.

A1.7. NR/UR. 102-1, The NORAD/USSPACECOM Integrated Command and Control System Mission Systems Integration Process.

A1.8. NR/UR 10-601, Integrated Tactical Warning and Attack Assessment (TW/AA) System Certification Process.

A1.9. UR 57-1, Operational Requirements System.

A1.10. NR/UR 700-1, Communications-Computer Systems Requirements Processing.

A1.11. Memorandum of Agreement between USSPACECOM and United States Atlantic Command, United States Pacific Command, and United States Strategic Command for the Integrated TW/AA System, 12 Mar 93.

A1.12. Memorandum of Agreement between NORAD, USSPACECOM, AFSPACECOM, NAVSPACECOM, USARSPACE concerning the formation and operation of the Integrated TW/AA Operational Integration Review Board and the Operation Integration Working Group, 13 Jul 88.

A1.13. Integrated TW/AA Configuration Control System Directive (CCSD) Volume II, Configuration Baseline, 22 May 1992.

A1.14. NORAD/USSPACECOM System Management Directive (SMD) for the Integrity of the Integrated TW/AA System, 1 Jun 93.

A1.15. NR 10-602, NORAD Operational Requirements System.

A1.16. NR/UR 60-101, The NORAD/USSPACECOM Interoperability and Standardization Guidance Policy.

A1.17. USSPACECOM Command, Control, Communications, Computer System Master Plan (C4SMP) Appendix H, NUICCS.

A1.18. USSPACECOM Communications ICD Standard for the Integrated TW/AA System, ITW/AA-STD-4000A, 19 Sep 91, Change 1, 27 Mar 92.

A1.19. System Integration Office Standard 1200A, SIO-STD-1200A, Advanced Data Communication Control Procedures (ADCCP) Within the Integrated Tactical Warning and Attack Assessment (TW/AA) System, 7 Sep 89, Revision 1.


A2.1. Communications Media. A media or means for transferring analog and digital data in a specified format. Includes MODEMs, multiplexors, cryptologic equipment, protocols, protocol handlers, data rates, and modes of transmission.

A2.2. Computer Hardware. Devices capable of accepting and storing computer data, executing a systematic sequence of operations on computer data, or producing control outputs.

A2.3. Computer Software. A combination of computer instructions and computer data definitions that enable the computer to perform computational or control functions.

A2.4. Configuration Item (CI). CIs covered by this regulation are communications media, computer hardware, computer software, and computer firmware.

A2.5.Configuration Management (CM). The technical and administrative direction and surveillance actions taken to identify and document the functional and physical characteristics of a CI; to control changes to a CI and its characteristics, and to record and report change processing and implementation status.

A2.6. Corollary Change. A change required as a direct result of some other changes (e.g., a proposed change may require a corresponding change at a sensor site prior to implementation. The site's change is a corollary change to the proposed change.).

A2.7. Firmware (F/W). The combination of a hardware device and computer instructions or computer data that resides as read-only software on the hardware device. The software cannot be readily modified under program control. This definition also applies to read-only digital data that may be used by electronic devices other than digital computers.

A2.8. Fit. The ability of an item to physically interface or interconnect with or become an integral part of another item.

A2.9. Fix. A change to correct deficiencies in a system not performing to the configuration item specification.

A2.10. Generic Change. The original standard change form (SCF), (NORAD/USSPACECOM Form 10, Standard Change Form) which initiates the operational approval staffing process for a desired configuration change. Related CI changes required as a direct result of a generic change are termed corollary changes.

A2.11. Implementing Organization. An organization (e.g., for acquisition and sustainment) that typically has CM responsibility for the CI baseline (e.g., while under acquisition and during operations), the resources, i.e., personnel and monies, to physically cause the change of a baseline, and is responsible to the operational user for system and CI performance.

A2.12. Interface Control Document (ICD). A document describing functional or physical interfaces between systems or configuration items within a system.

A2.13. Mission Software (Application Software). Supports or performs user-oriented tasks, or implements tactics or operational concepts, or directs the information exchange with other systems, or interacts with the user through displays and controls. Consists of mission operational and support software.

A2.14. Modification. An alteration, as a minimum, to the fit or function of an item or development of a new CI.

A2.15. Responsible Agency. A major command (MAJCOM) which provides resource management and program objective memorandum (POM) support for a warfighting CINC. This command has operational mission support responsibilities to another command but is not under operational command or operations control of that command (e.g., Air Combat Command, Pacific Air Forces, Canadian Air Command, and Canadian NDHQ/NWSO provide operational mission support to NORAD's atmospheric warning mission.).

A2.16. Site. A specific operational element of the Integrated TW/AA System (e.g., BMEWS Site I).

A2.17. Site Unique Change. A change affecting only one geographically distinct site.

A2.18. System Software. Software that allocates, controls, monitors, and supports hardware resources, or manages external interfaces, or translates mission software requests into hardware functions.

A2.19. System Unique Change. A change affecting common systems which are geographically separated (e.g., all four PAVE PAWS sites).

A2.20. Trial Period (TP). A scheduled period of time to verify and validate the mission capabilities and operational suitability of a system in an operational environment. For version releases, the date TP begins is called the version installation date (VID). TP is to demonstrate to the operational commander that the new or changed system can perform its designed operational mission or missions using production and organic resources. The period of time for this event depends on the complexity of the system or equipment acquired or modified, and end with the declaration of operational acceptance.

A2.21. Universal Control Number (UCN). A seventeen character alpha-numeric code assigned to every CI change. Used primarily to track the proposed change through the operation approval and implementation process.

A2.22. Version Agreement Date (VAD). The date a version release is approved by a change approval board or panel. This milestone is the date normally coincident with giving the support organization implementation authority.

A2.23. Version Content Notification (VCN). Formal declaration of the content of a version planned for release to a specific system(s). A VCN includes the version identifier (i.e., system, version release number), all associated UCNs with a short title of each, and a projected version installation date.

A2.24.Version Release. An identified and documented collection of hardware, software, firmware, or communications media configuration changes scheduled to be released at a specific date.

A2.25. Version Installation Date (VID). The date a version release is installed and used to support the system operational mission. This date begins the period called trial period (TP).

A2.26. Vertical Change. A change affecting two or more geographically separated sites.

A2.27. Vertical Release. Any vertical change requiring simultaneous implementation in Cheyenne Mountain Air Force Base (CMAFB) and at least one site geographically separated from CMAFB.

A2.28. Vertical Release Planning Meeting (VRPM). Normally a OAP or OASB subgroup meeting to define the proposed contents of a vertical release.


See figure A3.1, for operational change approval structure. This section describes the different change approval levels for the boards and panels. Each board and panel is identified by its respective roles and responsibilities and implementation actions. The scope of each board and panel Change Control Manager's (CCM) authority is defined by the type of standard change form (SCF) (i.e., modification or fix), its impact (i.e., is another system or subsystem outside the CCM's responsibility impacted), and resource availability (i.e., within implementing organization's organic and budgeted resources). Each board or panel chair, secretariat, members, and advisors are designated by the respective organization's operational user. The organizational office in figure A3.1 reflects who should designate the chairperson.

Figure A3.1. Operational Change Approval Structure.

A3.1. Operations Approval Board (OAB):

A3.1.1. Requirement actions:

A3.1.1.1. Approves/disapproves validated requirements (SCFs) affecting the systems assigned to two or more OAPs.

A3.1.1.2. Resolves issues on SCFs between OAPs.

A3.1.1.3. Provides technical integrity or integration issues to Mission Systems Integration Board (MSIB) in accordance with NR/UR 102-1, NUICCS Impact Criteria.

A3.1.2. Implementation actions:
Approves or determines the relative priority among SCFs affecting multiple OAPs and all Cheyenne Mountain AFB (CMAFB) modifications or "mods" to systems.

A3.1.2.2. Approves/disapproves the contents of a vertical release (i.e., those affecting multiple OAPs) and a CMAFB system version release involving modifications. Selects proposed solution(s).

A3.1.2.3. Approves the start and end of trial period for vertical and CMAFB releases.

A3.2. Operations Approval Panel (OAP).

A3.2.1. Requirement actions.

A3.2.1.1. Coordinates and forwards SCFs to the OAB for requirements affecting multiple OAP systems.

A3.2.1.2. Approves/disapproves validated requirements (SCFs) when:

A3. It does not affect other OAPs.

A3. It is forwarded by Operations Approval Sub-boards (OASB) affecting more than one OASB.

A3. A change affects any CMAFB system.

A3.2.1.3. Forwards all approved change(s) to other OAPs for information and appropriate action.

A3.2.1.4. Assigns priority for approved SCFs on systems with no other OAP impacts.

A3.2.1.5. Recommends to the OAB the proposed priority on SCFs affecting other OAPs and all CMAFB systems (i.e., modifications).

A3.2.1.6. Reviews other OAP validated SCFs for impacts and responds (e.g., corollary SCF impact) to originating OAP.

A3.2.1.7. Resolves issues affecting multiple OASBs under the OAP.

A3.2.1.8. When an operational requirement meets the NUICCS impact criteria, forwards one copy to the secretariat for the NUICCS Concept Review Subpanel.

A3.2.2.Implementation actions:

A3.2.2.1. Decides the relative priority between approved SCFs within the OAP's scope (i.e., rank order).

A3.2.2.2. Approves/disapproves the contents of a version release and selects proposed solution(s) for an OAP system unique SCF.

A3.2.2.3. Recommends version release contents and proposed solution(s) for vertical and CMAFB unique SCFs.

A3.2.2.4. Tasks implementing organization (through appropriate chain of command) to provide resource and technical analysis on OAP validated SCFs and to implement OAP and OAB approved SCFs. Note: Implementing organization's configuration control board (CCB) may meet at the same time as the OAP when authority rests within the scope of implementing organizations organic resources; and once System Program Director (SPD) and component command resolve funding when additional resources are required.

A3.2.2.5. Directs OAP secretariat or responsible organization to publish the VCN.
A3.2.2.6. Forwards technical integrity and integration issues to the NUICCS Technical Review Subpanel.

A3.3. Operations Approval Sub-Board (OASB).

A3.3.1. Requirement actions.

A3.3.1.1. Coordinates and forwards SCFs affecting multiple OASBs to the OAP.

A3.3.1.2. Approves/disapproves validated requirements (SCFs) when:

A3. It does not affect other OASBs.

A3. It is forwarded by a OARB and it does not affect another OASB (two level approval).

A3.3.1.3.. Forwards all approved change(s) to collateral OASBs and its OAP for information and appropriate action.

A3.3.1.4. Assigns priority for approved SCFs for systems with no other OASB impacts.

A3.3.1.5. Recommends to the OAP the proposed priority on approved SCFs affecting other OASBs.

A3.3.1.6. Reviews SCFs approved by other OASBs that were not specified as having impacts on collateral OASBs. As necessary, establishes, processes and forwards a corollary SCF to collateral OASBs and OAP.

A3.3.1.7. Resolves issues between OARBs under their OASB.

A3.3.1.8. When an operational requirement meets the NUICCS impact criteria, forwards one copy to the secretariat for the NUICCS Concept Review Subpanel.

A3.3.2. Implementation actions:

A3.3.2.1. Approves the relative priority between all approved SCFs within OASB scope (i.e., rank order).

A3.3.2.2. Approves/disapproves SCFs and selects proposed solution(s) for an OASB system specific version release.

A3.3.2.3. Recommends version release contents and proposed solution(s) to OAP for OASB changes(s) outside OASB approval authority.

A3.3.2.4. Tasks implementing organization (through appropriate chain of command) to provide resource and technical analysis on OASB validated SCFs and to implement OASB, OAP, and OAB approved SCFs. Note: Implementing organization's CCB may meet at the same time as the OASB when authority rests within the scope of implementing organizations organic resources; and once the SPD and component command resolve funding when additional resources are required.

A3.3.2.5. Directs secretariat or responsible organization to publish the VCN for OASB approved SCFs.

A3.3.2.6. Forwards technical integrity and integration issues to the NUICCS Technical Review Subpanel.

A3.4. Operations Approval Review Board (OARB).

A3.4.1. Approval actions:

A3.4.1.1. Coordinates and forwards SCFs affecting multiple OARBs to OASB.

A3.4.1.2. Recommends approval/disapproval on all SCFs (two level approval when no lower board or panel).

A3.4.1.3. Assigns priority for approved SCFs on systems with no other OARB (or higher) impacts.

A3.4.1.4. Recommends to the OASB the priority on SCFs affecting other OARBs.

A3.4.1.5. Reviews other collateral OARB validated changes that were not specified as having other OARB impacts. As necessary, establishes, processes, and forwards a corollary SCF to OARBs and OASB.

A3.4.2.Implementation actions:

A3.4.2.1. Approves the relative priority between all approved SCFs within OARB scope (i.e., rank order).

A3.4.2.2. Recommends approval/disapproval on SCFs for an OARB system specific version release.

A3.4.2.3. Recommends vertical release contents and proposed solution(s) to OASB for OARB change(s) outside OARB approval authority.

A3.4.2.4. Tasks implementing organization to provide resource and technical analysis on OARB validated SCFs and to implement OARB, OASB, OAP, and OAB approved SCFs. Note: Implementing organization's CCB may meet at the same time as the OARB when authority rests within the scope of implementing organizations organic resources; and once System Program Director (SPD) and component command resolve funding when additional resources are required.

A3.4.2.5. Directs secretariat or responsible organization to publish the VCN for OARB approved SCFs.


A4. Change Approval Process. The generic Integrated TW/AA System operational change approval process, also used for specified NUICCS configuration items (CI), is shown in figure A4.1. The description of the process flow is described below by individual process and decision figures. Each process and decision figure is described by its input, process, and output. The implementing organization (IMP ORG) is defined at attachment 2 para A2.11. A process or decision figure is labeled with a number and corresponds to its description below. (See figure A4.1 [Process/Decision Number]).

Figure A4.1. Integrated TW/AA Operational Change Approval Process.

A4.1.Change Request Submission [1].

A4.1.1. INPUT:

A4.1.1.1. Any individual or organization associated with the operational system may submit a completed Standard Change Form (SCF).

A4.1.1.2. A SCF forwarded from a lower, higher, or collateral operations approval board or panel (OAB/P).

A4.1.2. PROCESS:

A4.1.2.1. SCF Requirements. When an operational change is forwarded to a board or panel, the operations approval board or panel (OAB/P) Change Control Manager (CCM) (the chair) or designee e.g., secretariat:

A4. Verifies SCF blocks 1, 3, 4, 9, 11, 12, 13, and 16 are completed by the originator for a generic SCF.

A4. Verifies requirements are stated in operational vice solution terms.

A4. Verifies the originator's operations director signed the SCF in block 16 to certify the change meets baseline restriction (freeze) exception policy if appropriate.

A4. Decides when an SCF coming from a lower or collateral board is properly documented; such as, is the SCF signed in blocks 17 and 18 by the CCM or designated representative?

A4. Forwards the SCF to a lower or collateral OAB/P if introduced at a higher OAB/P.

A4.1.2.2. The signature of the originators operation director on an SCF in block 16 is verification of the requirement (not necessarily validation). The signature from the operations community on an SCF in block 18 is the initial validation of the change.

A4.1.2.3. All changes required to a operational system (i.e., CIs as defined at attachment 2, para A2.4), based on any requirement (e.g., Communications-computer systems Requirement Document (CSRD), Air Force Form 1067, etc.) must have an accompanying SCF submitted through the change approval process.

A4.1.3. OUTPUT: A SCF receiving validation at the first level OAB/P.

A4.2. Accept as Valid Requirement [2].

A4.2.1.INPUT: A SCF receiving first level validation from the operations community via signature in block 18.

A4.2.2. PROCESS:

A4.2.2.1. The change request is revalidated by a OAB/P.

A4.2.2.2. A "sanity" check is provided by OAB/P and ensures the request is still valid prior to requesting implementing organization initial analysis. The OAB/P determines:

A4. If the requirement can be satisfied by another means (i.e., changes in policy, procedures, training, etc).

A4. If an upgrade is already planned that will negate the need for this change.

A4. If it meets any exception policy criteria (e.g., baseline restriction) for a system.

A4.2.2.3. The implementing organization may provide a technical sanity check and identify whether a future release negates the need for the change and support the user's revalidation and prioritization of the requirement.

A4.2.2.4. The change is assigned a universal control number (UCN) as needed.

A4.2.2.5. The secretariat provides feedback to originator on all actions taken.

A4.2.2.6. The objective at this phase is to let the implementing organizations know as far in advance as possible of potential changes to allow orderly and routine processing and implementation; but to not request implementing organization initial analysis or initial engineering until change request is a realistic candidate for implementation.

A4.2.3. OUTPUT:

A4.2.3.1. Output of this block is a rough prioritization of requirements within a mission area.

A4.2.3.2. If accepted as a valid requirement, the SCF is merged into the priority list and forwarded to the implementing organization.

A4.2.3.3. If not accepted as a valid requirement at this point, the change is either:

A4. Deferred. A valid requirement but does not meet baseline restriction mission requirements, or valid requirement but does not meet criteria for initial analysis at this time.

A4. Deleted. No longer a valid requirement.

A4.3. Implementing Organization Analysis [3].

A4.3.1. INPUT: An SCF that is accepted as a valid requirement.

A4.3.2. PROCESS:

A4.3.2.1. Validated change requests are given to implementing organization(s) for determining estimated resources (funding, hours, duration), technical feasibility (hardware, software, communications, interoperability) proposed options, perceived risks, and recommendations. Any technical support provided at block 2 fosters a timely evaluation at this point. For example, an acquisition program, i.e., new contract effort, may be required to fulfill the change request.

A4.3.2.2. The preparation of the cost, schedule, performance impact analysis is used by implementing organizations configuration control board (CCB) for acquisition and sustainment (e.g., Air Force Materiel Command, Army Materiel Command).Detailed level design, specifications, coding, and documentation is not required during this activity period.

A4.3.2.3. Impacts on other systems, both in acquisition and in operation, other mission impacts, or issues that may be important are provided for the operator's decision on whether to continue. It is important to get both acquisition and sustainment impact analysis.

A4.3.3. OUTPUT: Output from the initial analysis is to give enough information for the implementing organization and OAB/P to:

A4.3.3.1. Determine if operational validation authority is within authority of current OAB/P (see responsibility statements at para A4.4).

A4.3.3.2. Determine if implementing organization has authority and resources to implement the proposed solution after decision is made by the OAB/P.

A4.3.3.3. Determine if change request is mutually understood by operator and implementer.

A4.3.3.4 Establish the initial estimates and schedule for use to track cost and schedule deviations.

A4.4.Evaluate and Revalidate the Requirement and Implementation Decision [4].

A4.4.1. INPUT: An analysis of the cost estimates, schedule, impacts to other systems (both in acquisition and operational), and perceived risks associated with the selected solution. The information must be sufficient for the operator's board/panel to make informed decisions on the risks, acceptability of the total system cost, approval authority and implementing organization.

A4.4.2. PROCESS:

A4.4.2.1. The analysis provided to operational decision makers for this activity is critical. The implementing organization supplies information to the operator allowing the operator to determine if the change:

A4. Is within approval authority of the current OAB/P (i.e. affects no other collateral board and second level of approval has been achieved). If not, forwards it to approval authority or collateral OAB/P. For corollary SCFs where lower OAB/Ps are not in agreement, the higher OAB/P decides on the action. [4A]

A4. Can be implemented within available resources.If not, identify the requirement and task the appropriate implementing or customer organization to begin necessary activity to accommodate the requirements (e.g., engineering change proposal (ECP), mission needs statement (MNS), service regulations covering modification approval and management, new acquisition, etc.). [4B]

A4. Is still valid.If not, the OAB/P documents the disapproval or defer decision and forwards the response to appropriate offices (e.g., Mission System Integration Board, component command operations organization (N3, G3, DO)). [4C]

A4. Affects a mission area outside of the Integrated TW/AA (e.g. launch systems, Mission System Integration Board, component command operational organization (N3, G3, DO)).If so, forwards it to the approval authority. [4D]

A4.4.2.2. Tasking is given to the office of primary responsibility or implementing organization for generating corollary SCFs for systems identified as impacted during the previous step.

A4.4.2.3. Select the best overall solution to meet requirements from the executable option(s).

A4.4.3. OUTPUT: A reprioritized list of operationally approved changes. When final validation is obtained, a change request becomes a candidate for a version release or product implementation (e.g., database of unscheduled change requests).

A4.5.Prioritize Change Request [5].

A4.5.1. INPUT: A list of validated and approved changes.

A4.5.2. PROCESS:

A4.5.2.1. Operator and implementing organization develop a recommended version release jointly (e.g., version release planning meeting (VRPM)) to ensure, (1) mission needs are met when required, (2) support implementation resources are available to produce the product, and (3) currency of the SCFs and to identify risks associated with SCFs.

A4.5.2.2. Recommended version release provided to OAB/P(s) for approval.

A4.5.3. OUTPUT: A prioritized list of validated and approved changes.

A4.6. Select Version/Vertical Release Contents (VCN) [6].

A4.6.1. Coordinate list of SCFs that are scheduled for a version release.
Incorporate approved changes by a higher OAB/P for a version release.

A4.6.2. Provide a "single point" of contact to implementer for the implementation activities (i.e., the "what" and "when").

A4.6.3. The approval of a vertical release content is made by the OAB (the same chairperson as the Operational Integration Review Board (OIRB), see attachment 1 para A1.12). The approval of a version release content is made by the appropriate OAB/P for the affected system. This milestone is defined as the version agreement date.

A4.7. Task Implementing Organization [7]. Submit documented release to implementing organization for action.

A4.8. Design, Implement, and Verify [8].

A4.8.1. This involves the detailed design, manufacturing, coding, documentation, request for service, i.e., the "how".

A4.8.2. The OAB/P ensures an operational user revalidates the change request product through appropriate design reviews, i.e., Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness Review (TRR), etc.

A4.9. Operational Test and Evaluation (OT&E) [9]. Implementing organization, testing organization (e.g., Air Force Operation Test and Evaluation Center (AFOTEC)), and user accomplish formal operational testing in an environment as operationally realistic as possible. For some version releases or system installations this period may be declared as follow-on operational test and evaluation (FOT&E).

A4.10. Installation Trial Period Decision [10].

A4.10.1. The OAB is the approval authority for CMAFB systems (the same chair as the Operational Integration Working Group (OIWG), see attachment 1 para A1.12), vertical releases, and decisions affecting multiple OAPs.

A4.10.2. If the decision is not to "install" the release, it is returned for appropriate action to the implementing organization or to the user if there are mission impacts.

A4.11. Trial Period, Certification [11]. The configured system is operated with operational data over a specified period. The system is evaluated for integrity prior to recommending system certification.

A4.12. Operational Acceptance/Certification Decision [12]. A OAB/P approves the system version for operational use and notifies operators and associated OAB/Ps.


A5.1. Standard Change Form (SCF).

A5.1.1. All agencies intending to request configuration changes to computer hardware, software, firmware, and communications media complete a NORAD/USSPACECOM Form 10 SCF (figure A5.1) for staffing and approval. This includes changes to configuration items defined as part of the Integrated TW/AA System and other NUICCS configuration items (CI) on a case-by-case basis (USSPACECOM policy letter).

A5.1.2. A change proposal impacting the operational baseline begins as an SCF. This includes acquisition programs integrating into the operational baseline. There are two processes required for a change to become part of the operational baseline: the SCF staffing and approval process, and the implementation process. The originator's operations director signs the SCF in block 16 as verification of the requirement. SCFs are submitted to the OAP/OASB responsible for initial requirement validation (block 18, CCM signature).

A5.1.3. Final approval of an SCF is intended to provide assurance that all impacts of the SCF on corollary systems, cost, schedule, and resources have been assessed. Final SCF approval does not assure implementation of a change; it provides information necessary for implementation planning and tracking.

A5.1.3.1. Generic SCF - The original SCF used to initiate the change (when the system ID, CI category, change type, or software type is unknown) is a generic SCF. Generic SCFs may be created to staff unique or multiple system changes. Initial validation of the requirement is noted by signature of the CCM in block 18. A higher level board or panel must make a final decision on a generic change when corollary changes are outside of the scope of the CCM. Final approval is not granted until all corollaries have been staffed and approved.

A5.1.3.2. Corollary SCF - Related changes required as a direct result of a generic SCF are termed corollary changes. Corollary SCFs are system specific and are created as the result of a generic SCF. The CCM signs a corollary SCF for those systems under his/her control.

A5.1.4. A user or operator at the appropriate level must validate a requirement submitted by any individual. A universal control number (UCN) is required for all changes (modifications, fixes, documentation, etc.) to the operational baseline and to integrate new development or system acquisitions into the operational baseline. For agencies who use other forms (e.g., software modification request, deficiency report, modification proposal, C4 systems requirements document, or equivalent DoD form, etc.) for identifying change requirements, a UCN must accompany the change form. Information in blocks 1 through 10, 14, 17, and 18 of an SCF must be included. Applicable documentation (e.g., interface control documents, system or configuration item specification) pages from the established configuration identification will be attached to the SCF during the staffing process.

A5.1.5. Figure A5.1. is a sample of the format for the SCF. The following information is included as part of the SCF staffing process:

A5.1.5.1. Corollary System Impacts - A corollary impact is a change required as a direct result of some other change. The CCM ensures other appropriate technical staffs or secretariats are apprised of the proposed change to determine corollary impacts. Corollary impacts are documented on an SCF. The corollary SCFs have the same title and first nine UCN characters as the generic SCF.

A5.1.5.2. Operational Employment - Performance, interoperability, reliability, maintainability and survivability. For implementation of new messages or significantly changing an existing message, a brief explanation is needed of the operator's intent on how they see the change affecting each end of an interface.

A5.1.5.3. Security - Impacts to system security. Communications-computer systems as well as physical security, information security, personnel security, and resource protection must be addressed throughout the life cycle of an automated system, regardless of the form generated.

A5.1.5.4. Resources - Resources needed to implement the change include:

A5. Manpower - The man-hours or man-days required.

A5. Computer Hours - Computer system clock hours required and the approximate time frame for accomplishing the proposed change.

A5. Testing - Equipment resource conflicts, test time, and test effort.

A5. Funds - Amount of funds required and probable source of those funds.

A5. Contracts - The feasibility of the proposed change within the scope of any existing contracts or potential impacts on any contracts.

A5.1.5.5. Acquisition Programs - Impacts to acquisition and development programs. Identify rough-order-of-magnitude impact assessment (i.e., cost, schedule, etc.) on acquisition and development systems in Block 16, "Remarks", on the SCF.

A5.1.5.6. Logistics Support - Support equipment, operator and maintenance training, spares, maintenance concepts.

A5.1.5.7. Schedules - Testing, vertical release, acquisition, etc.

A5.1.5.8. Documentation - Specifications, ICDs, technical manuals, and other documents in the established configuration identification. The most appropriate technical staff attaches available red-line page changes to the SCF.

A5.2. The Universal Control Number (UCN) - The UCN is a 17 character alphanumeric code assigned to every SCF. The CCM for the appropriate level board or panel is responsible for ensuring a UCN is assigned. It is used to track the proposed change through the change control process. The UCN format (with dashes added for ease of use) is explained below. When creating the generic SCF, the last five characters are displayed with Xs (e.g., 100-0001-91-010-XXXXX). Corollary SCFs are specific SCFs which must be implemented as a result of a generic SCF or another SCF. Corollary SCFs are identified using figure A5.2.

Figure A5.2. Universal Control Number.

A5.2.1.Change Control Manager Number - Every CCM has a three-digit number. The UCN shows the number of the OAP and OASB chairperson or designee who signed and validated the SCF. CCM numbers for each board or panel are located in reference A1.13.

A5.2.2. Log Number - A sequential four-digit number assigned by the OAP and OASB. Logs are maintained on a calendar year basis and includes numbers from 0001 through 9999.

A5.2.3. Calendar Year - The last two digits of the calendar year the OAP and OASB signed the SCF.

A5.2.4. Julian Date - The Julian date the OAP/OASB signed the SCF. Note: If the generic SCF is created in one calendar year and the corollary SCF is generated the following year or later, the corollary SCF will have a Julian date of 367.

A5.2.5.System ID - The two-letter identifier unique to the system for which the SCF was created. System IDs (both operational and development) are designated in reference A1.13.

A5.2.6. CI category - A one-letter code identifying the type of configuration item. The codes are H = "hardware", S = "software", F = "firmware", and C = "communications media".

A5.2.7. Change Type - A one-letter code identifying the type of change. The codes are:

A5.2.7.1. M = "modification" -a change to enhance a system (to include new system acquisitions).

A5.2.7.2. F = "fix" -a change to correct deficiencies in a system not performing to the system specification. The page and paragraph of the configuration identification specifying the performance not being met must be cited in Block 13 of the SCF.

A5.2.7.3. D = "documentation" -used to correct documentation-only (has no effect on software or equipment).

A5.2.8. Software Type - For software changes only, a one-letter code identifying the type of software change. The codes are:

A5.2.8.1. A = "application" (mission operational and mission support) software.

A5.2.8.2. S = "system" (system operational and system support) software.

A5.2.8.3. F = "firmware" being processed as software.

A5.2.8.4. Z = "other" - used when the change type is documentation or when the CI category is not software.


A6.1. SCF Assessment Decision - When a operations approval board or panel (OAB/P) convenes, the chairperson decides on each agenda item, based on the assessments of the members and advisors. If adverse impacts are identified, the chairperson may disapprove or defer the proposed change. If the decision is "Approval", "Approval with Concurrence", or "Recommend Approval", the chairperson makes a decision on the priority for each item. For each agenda item, the chairperson resolves items as follows:

A6.1.1. Approve - Two levels of approval are required on all changes prior to operations approval. If the change and all corollary changes are within an OAB/P's scope of responsibility, then the chairperson has approval authority. The Operations Approval Panels have authority to delegate the final approval of fixes to systems under their control to a lower OAB/P.

A6.1.2. Approve with Concurrence - An OAB/P with an originating SCF and with corollary changes outside its scope approves with concurrence when the other OAB/Ps approve the corollary SCFs. The OAB/P minutes include the corollary OAB/P's approval documentation.

A6.1.3. Recommend Approval - If the total change and all corollary changes are not within the OAB/P's scope of responsibility, the chairperson recommends approval to the higher OAB/P when concurrence is not received by other OAB/Ps.
A6.1.4. Disapprove with Comment - This constitutes final disposition of a proposed change and closes out the UCN.

A6.1.5. Defer with Comment - If the chairperson is not satisfied with the evaluation or staffing process of a proposed change, then disposition of the item is deferred until the board or panel convenes again.

A6.1.6. Withdraw with Comment - Used when a proposed change is removed by the originator or the signing OAB/P for the change.

A6.1.7. Cancel - Used when a proposed change is removed due to the sundown clause.

A6.2. Implementing Emergency, Urgent, and Temporary Changes:

A6.2.1. Emergency and urgent changes are changes which are processed and implemented outside of a normal scheduled version or installations applying to software, hardware, firmware, and communications.

A6.2.1.1. Emergency changes are implemented to correct problems demanding immediate resolution. Urgent changes are implemented for mission essential requirements which cannot be delayed until the next available scheduled version or installation. Each Operations Approval Panel defines their respective policy and procedures for emergency and urgent changes. HQ AFSPACECOM defines the nomenclature for identifying releases for emergency and urgent changes.

A6.2.1.2. Each Operations Approval Panel or designee is authorized to approve and implement emergency and urgent changes to their system. However, if other sites or systems are affected by the change, the OAB/P coordinates their actions with the affected OAB/Ps and system certification office prior to implementation. The operations or implementing agency notifies USSPACECOM, AFSPACECOM and OAB/Ps by telephone or message of the planned and implemented change as soon as possible.

A6.2.2. A temporary change does not become part of the permanent operational baseline. A temporary change is removed from the system at a predetermined time or condition. Temporary changes are staffed through an OAB/P. A planned version content notice (VCN) or installation message is completed and sent to HQ USSPACECOM and HQ AFSPACECOM before installing temporary changes. Upon installation and removal of the temporary change, an installation message is sent.