Exhibit_3d_TFITS_Requirements_Management_Plan.pdf

REQUIREMENTS MANAGEMENT PLAN (REQMP)

FOR THE

Total Force Information Technology Systems

(TFITS)

Version 1.0

June 15, 2013

PMM-110 IS&I Product Manager TFITS Marine Corps Systems Command

Stafford, VA 22554

SUBMITTED BY

Date Mr. Donya Johns Systems Engineer PdM TFITS, PMM-110

TECHNICAL REVIEW

Ms. Erneiliza Brown Systems Engineer PdM TFITS, PMM-110

CONCURRENCE

Mr. Andrew Mittura Assistant Product Manager – Engineer PMM110 IS&I, APdM-E TFITS

APPROVED BY

Mr. William Sandlin Product Manager (PdM) PM10 IS&I, APdM TFITS

Executive Summary Requirements Management (REQM) is a systems engineering process to manage and control requirements changes. It is the process of documenting, analyzing, tracing, prioritizing, and agreeing upon all requirements received or generated, including technical/performance (non-functional) and operational (functional) requirements. This process involves aligning changes to requirements and communicating those changes to relevant stakeholders. The Product Manager (PdM) TFITS REQM process begins with the requirements source documentation. This documentation is used to generate system and product component requirements, and then continues to be developed as those requirements are managed throughout the system life cycle.

This Requirements Management Plan (REQMP) defines the participants, products, and processes that support REQM for the TFITS product.

The PdM TFITS REQMP’s objective is to manage the Product Management Office (PdMO) manage project’s software requirements baselines through a REQM process. The projects must evaluate emerging requests for functionality corrections and enhancements from system users and stakeholders. During the system life cycle, new operational capability requirements will come from users and stakeholders in one of the following high-level requirements documentation:

• Business Case Analysis (BCA)

• Capability Design Documents (CDDs),

• Capability Production Documents (CPDs),

• Concept of Operations (CONOPS),

• Engineering Change Proposals (ECPs)

The capability documents contain Key Performance Parameters (KPPs) and Key System Attributes (KSAs). The BCA, CONOPS and ECPs contain operational requirements based upon end-users’ feedback on their use of their respective program/system, or request for new functionalities not documented in a capabilities documentation.

These requirements are analyzed, decomposed, baselined, and documented. From this process, requirements products, such as the System Design Specification (SDS) and Software Requirements Description (SRD) are derived. To manage requirements, a Requirements Traceability Matrix (RTM) is generated. This tool provides bi-directional (vertical and horizontal) traceability between the high-level requirements and their decompositions. In addition, the RTM shows the relationships between the operational or capability requirements (KPPs/KSAs), system performance and functional requirements and system designs, including test and evaluation methodologies, cases, pass/fail results, specifications and products Hardware Configuration Items (HWCIs) and Computer Software Configuration Items (CSCIs)). At any given time, the RTM may be updated, generated and used for each Systems Engineering Technical Review (SETR) events or as requested. PdMO Configuration Control Board (CCBs) and Integrated Product Teams (IPTs) have been established and chartered to serve as forums and authorities for reviewing, approving, managing, and implementing oversight and analysis of requirements and changes to requirements baselines.

http://en.wikipedia.org/wiki/Requirements_analysis http://en.wikipedia.org/wiki/Requirements_traceability http://en.wikipedia.org/wiki/Requirement_prioritization

Change History

This table identifies all changes incorporated into the updated version of this document after initial approval. A change in twenty percent (20%) of the document constitutes a new version.

Date Version # Change Description Author

Refer questions concerning this REQMP to:

• Donya Johns, TFITS Systems Engineer, 703-784-4778, donya.johns@usmc.mil

• Erneiliza Brown, TFITS Systems Engineer, 703-784-4749, erneiliza.brown@usmc.mil

• Andrew Mittura, TFITS APdM-E, 703-784-4740, andrew.mittura@usmc.mil

• William (Pete) Sandlin, TFITS PdM, CCB Chairman, 571-247-4482, william.sandlin@usmc.mil

Table of Contents

1. Introduction

1.1 Scope

1.2 Objective

2. Reference Documents

3. Requirements Management Process Preparation

3.1 Roles and Responsibilities

3.1.1 Product Manager (PdM)/Project Manager (PjM)

3.1.2 Assistant Product Manager – Engineer (APdM-E)

3.1.3 Project Engineer/Systems Engineer

3.2 Change Manager (ChM)

3.3 System Integrator (SI)

3.4 Engineering Review Board (ERB)

3.5 Relationship of IPTs to Requirements Management

4. Requirements Management Implementation

4.1 Requirements Statements

4.1.1 Example Requirements Statements

4.2 Requirements Management

4.3 Technical Baselines

4.3.1 Requirements

4.3.2 Products

5. Requirements Traceability

6. Requirements Change Management

6.1 Requirements Change Management Objectives

6.2 Change Procedure

7. Measures and Reports

7.1 Measurement Strategy and Structure

7.1.1 Measure Collection and Reporting

7.1.2 Measure Structure

7.2 Requirements Management Measure Specifications

7.2.1 Measure Summary

7.3 Requirement Management Measure Description Details

7.3.1 Requirements Stability

7.3.2 Requirements Completeness

7.3.3 Requirements Slippage

7.3.4 Percent Requirements Designed

7.3.5 Requirements Test Coverage

7.3.6 Requirements Defects – Design

7.3.7 Requirements Defects – Test

7.3.8 Orphan Requirements

Appendix A RTM Templates Appendix B Acronym List

Table of Figures

Figure 1 Technical Requirements Development Process Figure 2 Contractor RTM Template Figure 3 Requirements Logical Data Model Figure 4 Government RTM Template Figure 5 Requirements Change Management Process Figure 6: Measurement Strategy Figure 7: Measure Structure Figure 8 Requirements Stability Figure 9 Requirement Change Summary

List of Tables

Table 1: TFITS Managed Projects Table 2: Relation of TFITS Integrated Planning Teams to Requirements Management Table 3: Octet Change Delivery Days Table 4 TFITS Requirement Management Measures

1. Introduction Requirements Management (REQM) is a Systems Engineering (SE) discipline that formalizes the process of developing and maintaining requirements as well as controlling any changes to those requirements throughout the system life cycle. The key REQM principles when applied to PdM TFITS ensures that all requirements can be properly assessed, developed, validated, prioritized, and managed with measureable outcomes.

The purpose of this Requirements Management Plan (REQMP) is to define the participants, products, and processes that support REQM for the PdM TFITS projects. This plan defines how PdM TFITS requirements baselines (functional and allocated), supporting processes, and documentation are defined, managed, changed, and audited. The intended audience for this document is the TFITS PdMO, its supporting agencies, and TFITS Development Contractors (hereafter referred to as Systems Integrators (SIs). It also applies to TFITS IPTs, Working Groups (WGs) and other Government personnel who have oversight responsibilities for TFITS projects.

1.1 Scope

This REQMP defines the processes by which the PdMO will manage, control, execute, and document the various levels of requirements for the TFITS managed projects listed in Table 1.

Table 1: TFITS Managed Projects

Project Name Acronym Automated Manifest System-Tactical AMS TAC Radio Frequency Identification RFID Automated Tool Inventory Control and Tracking System ATICTS Joint Force Requirements Generator II JFRG II MAGTF Deployment Support System II MDSS II Defense Readiness Reporting System- Marine Corps DRSS-MC Marine Corps Recruiting Information Support System MCRISS Manpower Mobilization Assignment System MMAS Web Based Manpower Assignment Support System Web MASS Manpower Models MODELS Paperless Acquisition- PRBuilder PR Builder Standard Procurement System SPS Total Force Data Warehouse TFDW Automated Performance Evaluation System APES Total Force Retention System TFRS Performance Evaluation System PES Optical Digital Imaging-Records Management System ODI-RMS Defense Messaging System DMS Drill Management Module DMM Marine Corps Training Information Management System MCTIMS Theater Medical Information Program-Maritime TMIP

Total Force Structure Management System TFSMS Secure Personnel Accountability SPA

This document is organized to best suit the TFITS product portfolio and is divided into sections based on the key activities and functions of REQM: REQM Process Preparation, REQM Implementation, Requirements Traceability, and Requirements Change Management. In addition, this plan includes the identification of requirements documents, such as specifications, and other documents that allow for traceability. This traceability connects the lowest-level end product to the system specifications and then to the operational capability requirements document, from which these end products were derived.

The PdMO has the responsibility for executing this plan under the direction of the Product Manager (PdM). Additionally, where services have been contracted, the Systems Integrator shall develop and execute a REQM process that addresses and coordinates with the processes, products, and objectives described in this plan. This REQMP is considered a living document and will be updated as necessary to support evolving product needs and maturing projects and processes.

1.2 Objective

The REQM objectives for each project are:

• To provide effective processes for:

o Eliciting accurate and properly defined requirements for implementation that are executable and testable o Properly analyzing and decomposing requirements down to system, software, and hardware level specifications using formal methods to maintain traceability throughout the software development lifecycle o Establishing criteria for the analysis of requirements to ensure consistency and engineering rigor o Assuring thorough and proper documentation of requirements o Prioritizing requirements, taking into account resources and stakeholder needs

• To provide measureable guidance through effective metrics for requirements stability, correctness, and maturity

• To provide measurable guidance for the verification and validation of all requirements through effective metrics and testing

• To control requirements changes and the disposition of those changes

• To communicate progress on issues through accurate and meaningful reports

2. Reference Documents This section lists references used in preparation of this document.

(a) Department of the Navy (DON) Software Process Improvement Initiative (SPII) issued by the Assistant Secretary of the Navy (Research, Development & Acquisition) (ASN (RD&A)) dated November 17, 2006

(b) DON Software Measurement Policy for Software Intensive Systems, July 2008

(c) Guidebook for Acquisition of Naval Software Intensive Systems Office of the ASN (RD&A) v 1.0 dated September 2008

(d) IEEE 12207-2008 Systems and Software Engineering – Software Lifecycle Processes dated March 8, 2013

(e) ISO 15939: 2007 - Systems and software engineering -- Measurement process

(f) PEO TSC Instruction 4810.2, Software Development, Verification and Validation

(V&V), Design Reuse, and Metrics Policy,

(g) TFITS Configuration Management Plan (CMP) v 1.0 dated March 8, 2013

(h) TFITS Systems Engineering Plan (SEP) draft

(i) TFITS Software Test & Evaluation Strategy (ST&ES) draft

3. Requirements Management Process Preparation The REQM process begins with the development and preparation of this REQMP, including the identification of: REQM tools and resources, a set of defined requirements (operational and technical requirements along with derived requirements), approved system specifications, and the verification and validation methodologies. In addition, anticipated changes are identified, producing a management strategy that includes a bi-directional (vertical and horizontal) requirements compliance matrix with status related to change.

In the context of REQM, systems engineering is applied at the initial stages of project formulation and throughout the system life cycle in the following ways:

• Provides the integrated technical basis for project plans and acquisition decisions

• Manages technical requirements, risk assessments, and design trade-offs

• Integrates engineering, logistics, test, and life cycle management efforts among all stakeholders

• Transforms needed operational capabilities into an integrated system design through concurrent consideration of all life cycle needs

• Integrates the technical efforts related to system and software design and development, verification, deployment, operations and support, disposal, and user training for systems and their life cycle supporting products and services

• Develops credible and timely technical information to support the product management decision-making process

3.1 Roles and Responsibilities

The TFITS REQM structure features an integrated organization that coordinates with all product key functional elements. In TFITS, the requirements management structure interfaces with functions related to SE, interface control, Configuration Management (CM), risk management, and cost control. In support of this effort, each Project Management Office (PjMO) will establish an Engineering Review Board (ERB) and a Functional Review Board (FRB).

Currently, a CCB is established along with various IPTs to serve as forums and provide authority for reviewing, approving, managing, and providing oversight of requirements and changes to the requirements baseline. The TFITS CMP provides additional details regarding the FRB, ERB and

CCB.

3.1.1 Product Manager (PdM)/Project Manager (PjM)

The PdM is accountable for the management and execution of the TFITS product. Project management is delegated to the Project Managers (PjM). Each PjM chairs the CCB, and manages each TFITS project development areas such as cost, schedule and performance. The PjM is responsible for developing project capability in support of source requirements with programmatic constraints.

3.1.2 Assistant Product Manager – Engineer (APdM-E)

The APdM-E provides oversight and direction for the overall REQM process within established product constraints to ensure that REQM objectives are achieved.

In the context of REQM, the APdM-E is responsible for the following tasks:

• Supervise and oversee the establishment and revision of TFITS requirements baselines

• Supervise and oversee the change management of requirements, specifications, and identification of required standards

• Supervise and oversee the review of proposed technical revisions to the baseline

• Chair technical reviews and audits

• Supervise and oversee the development and implementation of new technical approaches to existing processes, products, and operational concepts

• Supervise and oversee the requirements measurement and metrics implementation

3.1.3 Project Engineer/Systems Engineer

A PdM TFITS Systems Engineer (SE) assigned to TFITS project(s) acts as the Requirements Manager (REQMgr) and Change Manager (ChM) for that project and is delegated chair of the project ERB. In addition, the SE works with the Project Manager the CCB, Configuration Management IPT (CMIPT), and the SI throughout the project’s life cycle.

As a REQMgr the SE is responsible for the following tasks:

• Assessing source and derived requirements and their impact to system development, implementation, and test

• Supporting the development and implementation of system specifications

• Supporting the verification and validation process relating to requirements through the system verification and system functional reviews

• Supporting prioritization efforts for requirements

• Controlling and maintaining all requirements baselines and related documentation

• Supporting all meetings where proposed requirements baseline changes are discussed

• Supporting configuration audits, conducts configuration self-audits, and SI audits

• Defining the tools necessary to provide required requirements traceability

• Ensuring the rationale for any requirement change is documented and that the impact of the change is understood

• Maintaining current REQM procedures, including coordinating technical writing for them

• Ensuring all requirements are measureable, verifiable, correct, unambiguous, traceable, attainable, and necessary

• Controlling and managing access to the requirements repository, defining access rights (create/read/update/delete) on a per user basis (An individuals’ access needs will be determined by the PjM and based on the individual’s level of involvement in the development process)

• Coordinating with appropriate stakeholders and users for review of requirements at designated SETR events

• Ensures timely and accurate data collection and analysis

• Conduct and chair project(s) ERB

3.2 Change Manager (ChM)

The ChM responsibility is described in detail within the TFITS CMP.

3.3 System Integrator (SI)

The SI shall maintain, manage, and provide further decomposition of the SDS and ECP requirements in the form of the Software Requirements Document (SRD) (i.e. Software Requirements Specification and Interface Requirements) and deliver a Contractor Requirements Traceability Matrix (C-RTM) throughout the development life cycle.

Please reference the SEP, and the CMP for documentation requirements appropriate for each level of software build release. At the minimum, the SI shall provide an RTM for all third octet (1.0.X.0) changes that captures the decomposed requirements for all ECPs planned for that software build.

In addition, the SI will provide requirements data/metrics at the applicable engineering event/review using available data collection methods per Section 7 of this plan.

3.4 Engineering Review Board (ERB)

The PdM-E or designated System Engineer (SE) /ChM chairs the ERB with participation from the SI as described in the TFITS CMP.

Within the context of REQM, the ERB performs an initial technical analysis and review of ECPs and its supporting documentation for

• Completeness of the requirement/request

• Identification of technical, performance, and functional requirements

• Impact and relationship to system/software and product configuration items

• Level of requirements review required with respect to the scope of the requirement

• Requirements elicitation effort necessary for identification and capture of detailed requirements

The result of the ERB activity will result in the ECPs workflow for escalation into the CCB for all Class 1 ECPs.

3.5 Relationship of IPTs to Requirements Management

Each IPT will provide assistance to the PdM and PjM and ensures clear understanding of each REQM related product and standard procedure. The IPTs are responsible for evaluating, identifying, and tracking relevant REQM related issues according to Table 2. IPT membership consists of representatives from the PdMO, SI, and SMEs.

Table 2: Relation of TFITS Integrated Planning Teams to Requirements Management

IPT Name REQM Responsibilities Configuration Management IPT

(CM IPT)

Management and coordination of requirements baselines and changes to those baselines

Systems Engineering IPT

(SE IPT)

Coordination of Development SE issues with REQM

Test & Evaluation (T&E) IPT

(TE IPT)

Integration of new requirements into test plans and cases

Information Assurance (IA) IPT

(IA IPT)

Assessment of IA related requirements and their impact to the baseline

Sustainment and Modernization IPT

(SM IPT)

Coordination of Production SE issues with

REQM

Requirements Management IPT

(REQM IPT)

Organize the TFITS approach to requirements management.

Logistics IPT Assessment of logistics related requirements and their impact to the baseline (i.e. HW/SW specifications)

The IPTs will be used to evaluate selected changes to the baselines and to assess potential impact within their area of responsibility. However, the REQMgr is responsible for engaging the IPTs as required. The REQMgr will contact the IPT Chairs to place requirements related discussions on the agenda and will facilitate the REQM portion of the IPT meeting.

At a minimum, the IPTs should:

• Assist in the derivation of new system specification and requirements

• Assess alternatives to achieve new requirements

• Assess the impact of proposed requirements and its changes

• Identify all risks associated to the requirement

• Identify how the requirements can affect other Configuration Items (CIs) in the baseline

• Determine the test success criteria that will be used to decide whether the requirement has been met

• Review and approve designated requirement to move forward

• Provide a SME

The composition and specific areas of responsibility for each of the various IPTs are defined in the PdM TFITS Systems Engineering Plan.

4. Requirements Management Implementation A properly implemented REQM process will result in compliance with the established rules for identifying, executing, validating, and managing various requirements baselines as well as the guidelines for properly handling any discrepancies detected during verification, validation, production, delivery, or operation of the system. The REQM process will ensure the requirements statements are in the correct format. There are two sets of requirements documentation that can be developed. In both cases the SDS serves as the government Requirements Traceability Matrix (RTM) and the SRD serves as the contractor RTM. The following are requirements documentation generated for a PdM TFITS project(s)

• Acquisition Category Milestone Decision Authority (ACAT MDA) designated projects receives operational requirements through Joint Capabilities Integration and Development System (JCIDS); Combat Development & Integration (CD & I) in a capabilities documentation such as:

o Capabilities Development Document (CDD) o Capabilities Production Document (CPD)

• Non-Acquisition Category (Non-ACAT) projects such as AAP receives operational requirements through the Advocate in:

o Concept of Operations (CONOPS) o Business Case Analysis (BCA)

Any requirements not contained in these source documents that are determined to be necessary will be introduced using Engineering Change Proposals (ECPs). ECPs will have requirements traceability matrices associated with them that will show mapping back to the source documentation such as the project ECP Detailed Report generated via the PdM TFITS ECP Tracker in SharePoint.

4.1 Requirements Statements

To ensure understandable, traceable, and testable requirements, requirements statements should be well formed and apply the following guidelines:

• Each statement should be identified with a unique identifier.

• Each individual requirement statement should have only one “shall” statement and have only one action verb.

• Each statement should be verifiable by inspection, analysis, demonstration, or test methodologies.

• Each statement should be measurable and correct, where the requirement as stated can support design.

• Sets of requirements statements should not have stacked, embedded, or multiple “shall” statements in an alphanumeric paragraph or list.

• Each statement should have parent-child relationship to form traceability.

4.1.1 Example Requirements Statements

• The system shall provide users within different levels of the hierarchy a workflow notification upon changes of a document within the established business rules.

• The system shall provide an alert and restrict multiple users from editing the same element within a document at the same time.

• The system shall generate and print manning documentation < 60 seconds 100% of the time.

4.2 Requirements Management

The TFITS REQMP provides the bi-directional (vertical and horizontal) traceability, using “trace links,” required for tracking and reporting through an RTM. This can be done using a spreadsheet or a formal requirements management tool. See Appendix A for the TFITS RTM template. Figure 1 depicts the process for translating CDD/CPD/CONOPS requirements into technical requirements that the SI can use to develop those capabilities in TFITS. Figure 1 shows the process for developing technical requirements.

Figure 1 Technical Requirements Development Process

The TFITS SE plays a key role in controlling and managing the technical requirements development activities. During this process, the TFITS SE an analysis with the PdMO of the operational/capability requirements (KPPs, KSAs, other attributes) and derives from them detailed technical performance and functional requirements expressed in “shall” statements.

These set of requirements, captured in the SDS, provides input into the logical analysis process in order to establish the necessary basis for system development.

Source Documentation

Technical requirements development is tightly linked to the logical analysis and design solution processes. This relationship is important since some technical requirements will become fully defined only through system decomposition at later stages of development.

• During the requirements development process, the SI shall analyze and decompose top-level SDS requirements into logically complete and concise sets of detailed SRD requirements suitable for building a system and developing the solution. The SI shall support requirements elicitation activities to interview system users for capture of clearly defined and well organized capture, with the TFITS SE oversight. The outcome of this analysis forms the requirements that characterize and specify the functions and performance of the to-be designed solution. The detailed requirements shall be managed, controlled and traceable within a RTM. The RTM and the SRD shall be provided in the TFITS Systems Engineering Technical Reviews (SETRs).

In addition, the TFITS product end-users and stakeholders provide feedback on the fielded system in the form of change requests. These change requests are formally processed as ECPs, which capture operational requirements as a result of user requests for functional enhancements to support their activities and daily operations. The CMP provides more detail about the ECP process.

• The SI shall decompose ECP requirements into logically complete and consistent sets of detailed requirements suitable for maintenance releases and system enhancements. The SI shall support requirements elicitation activities to interview system users for capture of clearly defined and well organized capture, with the TFITS SE oversight. The outcome of this analysis forms the requirements that characterize and specify the functions and performance of the to-be designed solution. These requirements are expressed in RTM, Figure 2 provides a view of proposed RTM format:

Figure 2 Contractor RTM Template

4.3 Technical Baselines

The REQM process identifies, analyzes, records, and tracks requirements for the system, end products, subsystems, and enabling products through the use of a REQM tool. These requirements, especially critical ones, are tracked between baselines and analyzed for unacceptable verification and validation results. These results are captured and maintained in an RTM. This activity ensures that an established requirements baseline is validated for bi-directional traceability with appropriate stakeholder commitment and/or approval captured.

The TFITS SEP provides a detailed explanation of the SETR process for programs in support of the baseline effort.

Figure 3 illustrates the structure of the requirements repository. This logical data model shows the notional data relationships between the system requirements (functional and allocated) baseline and the product baseline.

Product BL

Baseline (Functional/Allocated)

Software CI

PK Config ID

Software Name Version Description

Hardware CI

PK Config ID

Manufac Processor Memory (RAM)

CDD/CPD/CONOPS

PK Config ID

Description Treshold Objective

SDS

PK Config ID

Description Threshold Objective

Use/Test Cases

PK Config ID

Description Method Results

Interfaces

PK Config ID

System Name Protocols Inbound/Outbound

SRS/SRD

PK Config ID

Description Treshold Objective

SDD ID

ECP

PK Config ID

Description Class Status

TEMP/STES

PK Config ID

COI

MOP

MOE

MSur

Documentation

PK Config ID

File Name Name Version Date

Version Release

Version Number Description Date Source Codes

Reports

ID

Name Description

Forms

ID

Name Description

Workflow

ID

Name Description

Schemas

Name Description Module

Objects

ID

Name Description

RTM

PK Config ID

Description Treshold Objective

STP

PK Config ID

File Name Version

Figure 3 Requirements Logical Data Model

4.3.1 Requirements

Functional Baseline (FBL) The FBL is the initially approved baseline document describing the functional and performance requirements for a capability (or top-level configuration). Validation and verification is required to demonstrate that the functional and performance requirements are met. This baseline plus approved changes constitutes the functional configuration identification and serves as the description for required functional characteristics throughout the system life cycle. Government approval of the SDS and SRD constitutes the establishment of the FBL for each increment of capability. The PdMO shall manage and control the FBL at the conclusion of the System Requirements Review/System Functional Review (SRR/SFR). The SI shall provide the SRD and the update to the RTM prior to the review, refer to Table 3 for delivery dates. The TFITS SEP provides detailed information on the SETR process and includes the notional entry and exit criteria for the SRR/SFR.

Table 3: Octet Change Delivery Days

Octet Change Delivery Days 1st 30 (SIAT), 15 (PM)

1st and 2nd 15

3rd and 4th 5

3rd and 4th 5

Allocated Baseline (ABL) The ABL describes the allocation of the functional and performance requirements into the design constraints of the system and subsystems that will implement a capability. Each ABL consists of the allocated configuration documentation, which will be comprised of the current approved performance and design documentation governing the development of a CI. This level of documentation describes the system and subsystem requirements and characteristics and the verification required to demonstrate achievement of those specified characteristics.

• The SI shall manage and control the ABL at the conclusion of the Preliminary Design Review (PDR).

• The SI shall provide and update the SRD, system design documents, component specifications, RTM, and interface specifications, and other related documentation days prior to the PDR, refer to Table 3.

The TFITS SEP provides the notional entry and exit criteria for the PDR. Government control of the ABL is deferred until the Functional Configuration Audit (FCA) or the System Verification Review (SVR).

4.3.2 Products

Product Baseline (PBL) The PBL is the complete set of released and approved engineering design documents, including engineering models, interfaces, and database design documents for software. The PBL is managed by the PdMO and will be established at the conclusion of the Critical Design Review (CDR) and verified during the Physical Configuration Audit (PCA). In the context of REQM, the requirements related PBL include hardware, software, logistics, and all ECP related changes.

The TFITS CMP provides additional details about the PBL, and the TFITS SEP provides the notional entry and exit criteria for the CDR. Government control of the product baseline is deferred until the PCA.

5. Requirements Traceability The REQMgr assigns a unique identification number to each requirement statement. Each unique identification number is “trace linked” from the parent operational requirement to the derived technical and functional requirements in order to establish bi-directional (vertical and horizontal) traceability.

Figure 4 Government RTM Template

Figure 4 reflects the mapping between the various levels of requirements within the Government RTM, from the Source to the SDS level. The embedded templates in Appendix A cover both the government RTM and the contractor RTM in more detail.

6. Requirements Change Management Requirements change management provides:

• Requirement consistency and currency for requirements used in system design and product realization

• Control of the evolution of requirements baselines caused by requirements and design changes

• The capability to distinguish between versions of a particular requirements baseline and between the various requirements baselines

• Traceability between requirements changes to requirement baseline changes This activity is similar to the TFITS CM activity that is concerned with the systematic proposal, justification, evaluation, coordination, and disposition of proposed changes. This activity also incorporates all approved and released changes into the configurations and applicable documentation of the impacted requirements and any supporting and interfacing requirements.

The TFITS CMP provides detailed information regarding TFITS’ approach to managing baseline changes.

6.1 Requirements Change Management Objectives

The objectives of requirements change management are to:

• Ensure effective control of the requirements along with their documentation, traceability, and changes

• Provide effective means for proposing changes, requesting deviations, and preparing notices of revisions and change notices (A change notice is a document that provides information on an authorized change, such as what CIs need altering. A notice of revision is a document used to define changes to configuration documentation that require updating after ECP approval.)

• Identify and track proposed design solution requirements and requirements baselines

• Analyze each change to determine the impact on: the human aspects of design in operating the affected products, training, cost, schedule, and performance as well as determine if any risks exist

• Ensure that any vertical or horizontal issues are analyzed and resolved when a change is made to a product

6.2 Change Procedure

Figure 5 Requirements Change Management Process

Figure 5 covers the Requirements Change Management Process at a high level. This process begins with a stakeholder (advocate, PdMO, user, or SI) request to change or deviate from any type of requirement at any level and is broken down in more detail in the following steps.

Step 1: New/Change Requirement–A request for a new requirement or a change to an existing requirement is received by the PdMO, and the change management process is initiated.

Step 2: Analysis–The ERB performs the first level of analysis and reviews the request. The ERB then identifies any pre-existing requirements statements that may be modified or deleted by the new requirement; assesses the risks and impacts to any requirements, specifications, CIs, and documents.

Step 3: Approval (CCB)–The CCB performs an evaluation of the analysis and votes to either approve or deny the request. If the proposal is rejected, then the “Rejected Flag” is set for all associated requirements in the repository. Any notes and supporting documents associated to that requirement are also captured. This flag will prevent the rejected requirement from ever becoming part of the baseline and will preserve the analysis for historical purposes and future reference.

Step 4: Implementation and Verification–The implementation and verification process takes a new requirement or change and implements it as described in the following sub-steps.

Step 4.1: Requirements Analysis and Decomposition (e.g. Requirements Elicitation)–The requirements analysis and decomposition process includes the interview of the customer and other stakeholders responsible for identifying the required functionality in support of requirements elicitation. An analyst interviews the necessary stakeholders and engages the appropriate IPT to review, refine, and update or add additional levels of detail to the requirement. In addition, the analyst will capture the draft requirement in the requirements repository, noting the draft status via the use of a metadata tag.

Step 4.1.3: Functional Requirements–Some new requirements or changes support the system functionality. In these cases, the analyst will collect the required information to enable the implementation of functional requirements (e.g. list of values, user views, business rules, reports, data dictionary, and other related items).

Step 4.1.4: Technical Requirements–Some requirements support the technical performance of the system. In these cases, the analyst will collect the required information to enable the implementation of technical requirements (e.g. data on information assurance, net centricity, availability, reliability, maintainability, interoperability, and accessibility).

When finished, step 4.1 provides a complete understanding of the requirement and its allocation to the parent requirement. For the TFITS SE development process, requirements understanding and functional allocation of the parent requirement to the specification baseline is concluded in the SFR events.

Step 4.2: Requirements Allocation and Design–The PDR forms the basis by which the approved SRD level requirements statements and supporting items establish an updated ABL. The analyst and REQMgr remain closely engaged with the developers, testers, and trainers as they use the requirements to produce their allocated and design requirements for delivering the final end product. During this step, the analyst provides amplification of concepts and recommendations regarding the display of information as well as business process constraints.

Step 4.3: Design Synthesis and Solution Development–Development of the software proceeds in accordance with the SI’s software development process. The CDR provides the bases for the review of detail design specifications, drawings, diagrams, and other detail design documentations. The conclusion of this review provides an approved initial PBL.

Step 4.4: Integration– Developmental test, such as the integration testing, is conducted as outlined in the SI Software Test Plan (STP). During this step, the analyst continues to provide recommendations and business steps to be followed in test procedures and test cases.

The results of these tests are captured in the RTM. This step serves as an entry point to the

Test Readiness Review (TRR) prior to entry into operational testing activity to support the incremental development process. To support the TFITS Production Environment ECP process, this step serves as an entry point to the Government Acceptance Testing (GAT).

Step 4.5: Verification/Validation– This step is conducted as outlined in the TFITS System Test and Evaluation Strategy (ST&ES). Conclusion of this step serves as an entry to the PRR and government’s ownership of the allocated baseline as the system transitions to release. To support the TFITS Production Environment ECP process, this step is referred to as the GAT activity.

Step 4.6: Release to Production–Fully tested and integrated requirements that have been accepted by the government will be introduced into the production software in accordance with approved software release procedures.

Step 5: Manage Baseline via CM–Once the requirements have been released into production, the baselines are updated in accordance with CM process.

7. Measures and Reports TFITS has defined the following measures to be collected, analyzed, and reported at milestones, engineering reviews and at regular intervals throughout the project. Table 1 provides a listing of desired measures. The SI should document within their Quality Assurance Program Plan the approach for requirements measurement and reporting.

Table 4 TFITS Requirement Management Measures

Measure Purpose

Requirements Stability Indicates stability and the degree to which requirements are changing as compared to total requirements

Requirements Completeness Indicates uncertainty and ambiguity in the application as reflected by TBD requirements

Requirements Slippage Tracks requirements scheduled for each build versus requirements delivered

Percent Requirements Designed Indicates the maturity of the design

Requirements Test Coverage Tracks that requirements are being verified as planned

Requirements Defects – Design Review Indicates the cycle time for the arrival and closure of requirements defects during the design phase

Requirements Defects – Test Review Indicates the cycle time for the arrival and closure of requirements defects during the testing phase

Defect Removal Efficiency Indicates the defect closure rate and ability to efficiently correct defects

Orphan Requirements Indicates the number of lower level (child) requirements that cannot be traced to a system-level (parent) requirement

In order to facilitate the management, monitoring, and evaluation of requirements activities and products, TFITS requires that the SI use the requirements measures defined above as an integral part of their activities. These measures are based on project critical success factors associated with system requirements, system mission, programmatic constraints and concerns, and system-specific issues. The purpose of these measures is to provide:

• Progress against plans

• The extent to which system requirements are being met

• Critical product attributes such as quality and performance

• Timely and accurate information about the efficiency and effectiveness of the requirements management processes

• Status of current and impending risks

The SI should document in the Quality Assurance Program Plan the approach for requirements measurement and reporting. The SI should provide and generate measures as defined in this section.

7.1 Measurement Strategy and Structure

The overall objectives of the requirements measures are to:

• Provide insight into the status of the project

• Allow actions to be taken when actual results deviate from plans

• Enable root cause analysis of requirements, design, test, and change control process problems The measures will be used to support required milestone and engineering reviews as well as Probability of Program Success (PoPS) assessments throughout the program lifecycle. Figure 1 defines the phases of the RM performance measurement life-cycle described in this Appendix.

Figure 6: Measurement Strategy

7.1.1 Measure Collection and Reporting

All data collection will be performed by the responsible TFITS engineering and SI. Data storage will be achieved through the use of available tools, such as Microsoft Excel, Microsoft Access, or other SQL–based tools. Data analysis will be performed by the appropriate individual and groups identified below.

This Figure identified key engineering events conducted during the acquisition and development processes.

Table 4 Key SETR Events

Monthly SFR PDR CDR TRR GAT PRR Measure Required at Review Requirements Stability x x x x x x Requirements Completeness x Requirements Slippage x x x x x x Percent Requirements Designed x x Requirements Test Coverage x x x Requirements Defects – Design, Test x x x x Orphan Requirements x x x x x x

7.1.2 Measure Structure

The measure structure is based on a tailored measurement information model based on the International Organization for Standards (ISO) standard for system and software engineering measurement. This tailored model consists of three components as shown in Figure 2:

• Base Measure – A quantification of a single attribute; a focal point of data collection

• Derived Measure – A function of two or more base measures

• Indicator – A base and/or derived measure with decision criteria; a focal point of analysis.

Figure 7: Measure Structure

The purpose of this structure is to clearly and rigorously define basic measurement concepts in order to remove terminology ambiguity related to the components of the measurement process.

The Base Measure criteria and Indicator Specifications that follow conform to this measurement construct.

7.2 Requirements Management Measure Specifications

REQM Measure Data Description Items Each measure is further defined according to the following characteristics:

• Description: textual description of the measure

• Sample Indicator: Example of what the graphic/output of the measure should look like

• Planned Usage: How the measure will be used, what actions are taken given certain conditions, acceptable thresholds

• Base measure data collected: Identifies each data series (base measures) and any equations that are derived from base measures

• Data collection: Format for the collection – spreadsheet, MSR data, etc.

• Responsibility for data collection: Individual responsible for collection

• Collection frequency: Collection frequency: Monthly, Quarterly, etc.

• Data Analysis Individual/IPT/Group responsible for analyzing results

7.2.1 Measure Summary

The following table summarizes key components of the requirement management measures specified in following sections.

Table 5 Data Description Summary

Requirement Management Measure Base

Measures Collection

Method Collected

By Collection Frequency

Analysis By

Requirements Stability Total requirements new, deleted, changed

Counts of requirements;

Excel/data base

SI

TFITS -

Engineering

Monthly Key Milestones Events

Tier II/Tier III

TFITS -

Engineering

Requirements Completeness

Total requirements TBD requirements

Counts of requirements complete, testable, clear and concise;

Excel/data base

SI

TFITS -

Engineering

Monthly Key Milestones Events

Tier II/Tier III

TFITS –

Engineering

Requirements Slippage Per build:

Plan requirements Act. Requirements

Counts of requirements against time Excel/data base

SI

TFITS -

Engineering

Monthly/Key Milestones/Events

Tier II/Tier III

TFITS –

Engineering

Percent Requirements Designed Planned Comp Actual Comp.

Verified Comp.

Counts requirements against design components

SI

TFITS -

Engineering

Monthly/Key Milestones/Events

Tier II/Tier III

TFITS –

Engineering

Requirements Test Coverage

Total requirements Planned verified requirements Actual verified requirements

Counts of requirements against test cases and scripts Excel/data base

SI

TFITS -

Engineering

Monthly Key Milestones Test Events

Tier II/Tier III

TFITS –

Engineering

Requirements Defects – Design Review

Design Defect by status

Counts of requirements Excel/data base

SI

TFITS -

Engineering

Monthly/DR Tier II/Tier III

TFITS –

Engineering

Requirements Defects – Test Review Test Defect by status Counts of requirements Excel/data base

SI

TFITS -

Engineering

Monthly/TRR/PR R

Tier II/Tier III

TFITS –

Engineering

Defect Removal Efficiency Total Open defects Total Closed defects

Counts of defects by status

SI

TFITS -

Engineering

Monthly Tier II/Tier III

TFITS –

Engineering

Orphan Requirements Total Reqmts.

Orphan Reqmts.

Counts of Total and orphaned reqmts.

SI

TFITS -

Engineering

Monthly/RTM analysis

Tier II/Tier III

TFITS –

Engineering

7.3 Requirement Management Measure Description Details

7.3.1 Requirements Stability

All requirements changes are tracked and managed when the Software Requirements Descriptions or applicable Requirements Traceability Matrix are placed under configuration control. Requirements stability measures monitor the total number of requirements, new and deleted requirements, and changes to requirements. Requirements changes are to be tracked and reported in tabular form in three categories:

• Functional changes – intentional changes to the functionality or behavior of the requirements. These changes present risk to the development process in that they will likely require reworking the product’s design and code. The later in the life cycle they appear, the higher the schedule and cost impact.

• Clarification changes – changes to the requirements that affect interpretation but do not change the intended behavior. Such changes include clarifications, refinement of detail, and removal of ambiguities. While these changes do not intentionally change behavior, they may cause rework if the developers’ interpretation of the requirements were inconsistent with the intended behaviors.

• Textual changes – changes that affect only the syntax of the requirements statement. Such changes include typographical errors, misspellings, and grammatical errors. These changes usually do not cause rework, but represent the care and attention placed into writing the requirements, and as such suggests the overall quality of the requirements.

Requirements stability is computed as the percent of changes made to requirements where stability is displayed in relation to total requirements. A sample Requirements Stability indicator is shown in Figure 3.

Figure 8 Requirements Stability

739 739 739 739

747 749 750 750 750 750

12% 10%

6%

3% 2% 2% 2% 2% 1% 1% 0% 0% 2% 3%

0% 0% 0%

5%

10%

15%

20%

25%

30%

St ab ili ty

N um be r o f R eq ui re m en ts

Threshold % Total Requirements Stability %

In addition, a detailed report containing a breakdown of all requirements changes may be provided each month, including a chart as shown in Figure 4, Requirement Change Summary.

Figure 9 Requirement Change Summary

The determination of whether a change is a clarification or a textual change may be in many cases subjective. SI should use best judgment in making these allocations. In general, textual changes are likely to be misspellings or grammatical errors, while clarifications tend to be rewordings.

The base measure data to be collected includes counts of:

a) Total requirements as of the end of the reporting period

b) New – New requirements that were added during the reporting period

c) Deleted – Existing requirements that were deleted during the reporting period

d) Functional – Requirements that experienced Functional changes during the reporting period

e) Clarifications – Requirements that were clarified and had no functional changes during the reporting period

f) Textual – Requirements that experienced textual changes but no functional changes or clarifications during the reporting period

g) Unchanged – Requirements that experienced no changes during the reporting period

Requirements Stability is a derived measure based on the following equation:

725 715

725 730 736 739 739 739 739 747 749 750 750 750 750

To ta l R eq ui re m

N um be r o f C ha ng es

Clarification Functional New Deleted Total Requirements

UnchangedTextualionsClarificatFunctionalDeletedNew FunctionalDeletedNew

7.3.2 Requirements Completeness

During requirements development,…