CLR 252 Developing KPPs Note from SME: Changes to text are marked in Red. If just the title is in red, that is all that is changed—If the title AND text (or partial) changed—it will be marked.   EXCEPTION—If there is a new DIAGRAM—I only marked the title/header—to not “mess up” the diagram.

LESSONS Lesson #1 – Requirements Foundation Lesson #2 – KPPs, Performance Attributes and Requirements Creep Lesson #3 – How to Write a Good Requirement Lesson #4 – Requirements Validation Lesson # 5 – Net Ready KPP

Lesson #1: Requirements Foundation Types of Requirements

Lesson Objectives Terminal Learning Objective Describe the basis of performance attributes and KPPs Enabling Learning Objectives Identify User gaps Describe objective analysis Define Requirements and distinguish between types of requirements

Lesson Overview Requirements Objectives Defined and examples Potential problems defining requirements Stakeholders, Customers and Users Types of requirements Capabilities and Evolutionary Acquisition Objectives Characteristics Analysis Functions

Definitions Some terms that will help you understand the material in this course: Capability – The ability to execute a specified course of action. (A capability may or may not be accompanied by an intention.) Capability Gap (or Gap)– The inability to execute a specified course of action. Capability Requirement (also called “need” or “requirement”)– A capability which is required to meet an organization’s roles, functions, and missions in current or future operations. Capability Solution – A materiel solution or non-materiel solution to satisfy one or more capability requirements (or needs) and reduce or eliminate one or more capability gaps. *pop up details on notes page Capability Gap - The gap may be the result of no existing capability, lack of proficiency or sufficiency in an existing capability solution, or the need to replace an existing capability solution to prevent a future gap To the greatest extent possible, capability requirements are described in relation to tasks, standards, and conditions in accordance with the Universal Joint Task List or equivalent DOD Component Task List. If a capability requirement is not satisfied by a capability solution, then there is also an associated capability gap which carries a certain amount of risk until eliminated. A requirement is considered to be ‘draft’ or ‘proposed’ until validated by the appropriate authority.

Definitions Document Sponsor – The organization submitting a JCIDS document. DOD Components – The Office of the Secretary of Defense, the Military Departments, the Chairman of the Joint Chiefs of Staff, the Combatant Commands, the Office of the Inspector General of the Department of Defense, the Department of Defense Agencies, field activities, and all other organizational entities in the Department of Defense. Validation - The review and approval of capability requirement documents by a designated validation authority. *pop up details on notes page Document Sponsor - Solution Sponsors for successor documents – Capability Development Documents (CDDs), Capability Production Documents (CPDs), and Joint DOTmLPF-P Change Recommendations (Joint DCRs) - may be different than the Requirement Sponsors for initial documents – Initial Capabilities Documents (ICDs), Urgent Operational Needs (UONs), Joint UONs (JUONs), and Joint Emergent Operational Needs (JEONs). Different Sponsors for requirements and solutions occurs most commonly when the initial requirement Sponsor does not have delegated acquisition authority and a different organization is designated to develop and field a capability solution. The JROC is the ultimate validation authority for capability requirements unless otherwise delegated to a subordinate board or to a designated validation authority in a Service, CCMD, or other DOD Component.

Capability Requirements – Mission Related Capability Requirements Represent: Capabilities required for current mission accomplishment Capabilities required for new missions, based on identified gaps Opportunities to better accomplish current or new missions created by technology Potential Problems: New required capabilities may exceed resources Maturity of Technology Insufficient or inadequate analysis Conflicting Agendas

Examples of Mission-Level Capability Requirements Move 1000 combat loaded airborne infantry troops 1500 miles in 5 hours Transport 40,000 pounds of payload from Earth surface to low Earth orbit Safely transport 3 to 5 people on road networks in comfort

Capabilities and Gaps Potential Problems with Written Capabilities and Gaps Vague Incomplete Symptomatic Restrictive Too subjective Imply a specific solution

Information Collection It is important to work closely with the warfighter to reconstruct a mutually agreeable capability statement Identify User Community How To? By doing this: Sampling Questionnaires Observations Interviews Consulting historic records Understand Environment Understand Current Operations

Capability Gap Analysis Illustration Determine Capability Gaps Operational Deficiency Current and Future Mission Requirements Understand Environment Document Required Capabilities New Ideas Understand Current Operations Advances in Technology The Requirements Manager must collect information concerning the warfighters mission capability requirements

Requirements Feed the Acquisition Process Full Rate Prod Decision Review Joint Concepts Capabilities - Based Assessment MS C MS B Strategic Guidance MS A Technology Development Engineering & Manufacturing Development Production & Deployment AoA Materiel Solution Analysis Technology Opportunities & Resources ICD O&S User Needs MDD CDD CPD Post CDR Assessment Pre-EMD Review Incremental Development Draft DoD Requirements are expressed by: Initial Capability Document (ICD) or Capability Development Document (CDD) Source: DoDI 5000.02

Requirements Reflective Question: Write a requirements statement for a remote control that can work for all the electronics in your entertainment center.

Objectives Why objectives? 1. Convert User Needs into specific statements of the top-level goals and functions of the system. 2. Provide a bridge between the language of the user and the language of the engineer/requirements manager Characteristics of Objectives: 1. Verifiable/measurable 2. Feasible 3. Logical and non-redundant 4. Communicate the overall need

Objective Analysis What is objective analysis? Step 1. The process of defining objectives of the system and ordering them in a hierarchical structure. Step 2. Defining a set of measures (or metrics) for each objective.

Overarching Objective Objective Analysis Product: One single statement, what & why we are doing this, what this system is about An objective tree… Overarching Objective Primary Objective Primary Objective Primary Objective Function

Objectives vs Functions Primary Objective: A statement of purpose expressing a desired satisfaction of required capability; related to why a system is wanted. (No numbers or values) Examples: Provide a comfortable ride Provide clean clothes Get a vehicle that can carry the family camping Function: An activity which the system should perform or support. Functions state what the system should do (verbs). Examples: Supply electricity Transmit commands

Objectives Objectives: Express shortfalls as gaps in capability State definable characteristics Let users and decision makers prioritize Describe what a system should do (function) and why the user needs it (to fill a defined gap)

Objectives Reflective Question: Write 3 Objectives for your next car purchase. -Are they Verifiable/measurable? (Can you measure “A car that looks good?”) -Feasible? (Realistic, within your own constraints) -Logical and non-redundant (4 wheel drive vs sports car in heavy winter snow area) -Communicate the overall need (Safety, Transportation, ect)

Objectives Knowledge Review: The steps for an Objective Analysis are: 1. Prioritize each objective, then 2. Define a set of measures for every objective a. True b. False

Distinction Between Stakeholder and User Stakeholders are acquirer, user, customer, manufacturer, installer, testers, maintainer, or program manager User is either an individual or organization that uses the end product of a system Know the difference between stakeholders and users. They each have their own set of requirements.

Types of Requirements Capability Requirements Capabilities to achieve military objectives identified in a CBA (described in the ICD) – 2. Operational performance attributes at a system level necessary for the acquisition community to design a proposed system(s) and establish a program baseline (described in the CDD/CPD). KPPs, KSAs, and additional performance attributes Other system attributes **pop-up on notes page Capability Requirements Capabilities identified during a CBA that are required to achieve military objectives (described in the ICD) – Must contain the required operational attributes with appropriate quanitative parameters and metrics, e.g., outcomes, time, distance, effect (including scale), obstacles to be overcome, and supportability. General enough so as not to prejudice decisions in favor of a particular means of implementation but specific enough to evaluate alternative approaches to implement the capability. Operational performance attributes at a system level necessary for the acquisition community to design a proposed system(s) and establish a program baseline (described in the CDD/CPD). KPPs, KSAs, and additional performance attributes Other system attributes: design, cost and risk drivers, including ESOH, HSI, embedded instrumentation, electronic attack, information protection standards and information assurance requirements.

. Types of Requirements Technical Requirements characterize and specify the functions and performance of the design solution (described in the contract/spec) 1. Derived from analysis of operational requirements. 2. Establish the basis for system development. 3. Expressed in specification, subsystem specifications, and test criteria ** pop-up on notes page Derived Requirements: Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight. (Source: DAU, Systems Engineering Fundamentals, chapter 4)

Requirements Now that we have looked at definitions, determining objectives and types of requirements, we can link them all to the acquisition process for developing, producing and fielding solutions to meet the warfighter’s needs

Linking Desired Effects, Stakeholders and Requirements Desired effects and needed capabilities drive DoD requirements. All stakeholders in the requirements and acquisition process must understand why the warfighter needs a particular capability, who will use it, how and where it will be employed when it is needed and how it will be supported. Capability requirements developed using the JCIDS process drive the acquisition process to develop, produce and field a materiel solution to resolve or mitigate gaps in warfighting capability Successful requirements development requires early and ongoing collaboration among operators, developers, acquirers, testers, sustainers and operations analysts.

The Defense Acquisition System The primary objective of the Defense Acquisition System is to acquire quality products that satisfy user needs with measurable improvements to mission capability and operational support, in a timely manner, and at a fair and reasonable price (DoDD 5000.01) To achieve this goal, all stakeholders must collaborate in planning and execution activities that lead to developing, fielding and sustaining new operational capabilities. After requirements managers define and approve required capabilities and performance attributes, those attributes guide development, test and evaluation, production, procurement, deployment, and sustainment of the new capability. The program manager must work with the requirements manager to balance cost, schedule, and performance in response to approved capability requirements documents.

Evolutionary Acquisition Evolutionary acquisition is the preferred DoD strategy for rapid acquisition of mature technology for the user. An evolutionary approach delivers capability in increments, recognizing, up front, the need for future capability improvements. The objective is to balance needs and available capability with resources, and to put capability into the hands of the user quickly. The success of the strategy depends on phased definition of capability needs and system requirements, and the maturation of technologies that lead to disciplined development and production of systems that provide increasing capability over time. Evolutionary acquisition requires collaboration among the user, tester, and developer. In this process, several increments meet a needed operational capability over time. Developing each increment depends on available mature technology. .

Evolutionary Acquisition Developmental Approach Technology development preceding the initiation of an increment shall continue until the program achieves the required level of maturity and produces either the system or key system elements. Successive Technology Development Phases may be necessary to mature technology for multiple development increments. .

Evolutionary Acquisition . Each increment is a militarily useful and supportable operational capability that DoD can develop, produce, deploy, and sustain. The user will set the threshold and objective values for each increment. Block upgrades, pre-planned product improvement, and similar efforts that provide a significant increase in operational capability and meet an acquisition category threshold specified in this document shall be managed as separate increments under DoDI 5000.02.

Requirements Reflective Questions Are there any requirements in the programs you are currently working that are implied or derived from operational requirements? If so, how have they impacted your trade space? If not, what possible impact may result due to operational requirements? What is a requirement that is derived from the analysis of operational requirements? a. Functional Requirement b. Derived Requirement c. Technical Requirement d. Performance Requirement

Lesson Review Objectives Requirements Managers need to justify and prioritize objectives Requirements Requirements should state what the system should do, not specify how the system is to do it – dealing with what is acceptable to a stakeholder – both in terms of thresholds and objectives Technology can redefine a gap or potential in capability

LESSON #1 TEST ELO #1 How are capability requirements derived? a. Deficiency in the current system b. New desired capability c. New opportunity created by technology d. All of the above

LESSON #1 Which is the best example of a requirement? a. A shoulder-fired anti-tank weapon that can penetrate 3 inches of armor b. Be able to destroy a T-72 sized target at a 3 mile stand-off range c. A TOW variant compatible with the Bradley digital upgrade d. A new tank-destroying air to ground missile What must the designer and requirements manager first do to conduct user needs analysis? a. Identify Users, Understand Environment, Understand Current Operations b. Conduct a cost comparison and direct a specific solution c. Prioritize objectives and define a set of measures d. Use new technology to define a need

LESSON #1 ELO #2 What are some characteristics of valid objectives? a. Verifiable/measurable b. Communicate the overall need c. Feasible d. Logical and non-redundant e. All of the Above What do sound, valid objectives provide to a program? a. Helps to decide a specific solution b. Communicates the feasibility of the desired outcomes c. Provide a bridge between the language of the user and the language of the engineer d. Communicates the lowest acceptable level to the Acquisition community

LESSON #1 What process starts with defining objectives of the system and ordering them in a hierarchical structure then defines a set of measures (or metrics) for each objective? a. Service Component Acquisition Process b. JCIDS c. Service Component Requirements Process d. Objective Analysis ELO #3 What are Requirements that are implied or transformed from a higher-level requirement? a. Design Requirements b. Allocated Requirements c. Derived Requirements d. Implied Requirements

LESSON #1 From the list below, select the stakeholders in the outcome of a weapons acquisition program: Check all that apply. a. User b. Tester c. Program Manager d. Acquirer e. Customer