CLR 252 Developing KPPs

1. CLR 252Developing 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.

2. 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

3. Lesson #1: Requirements Foundation Types of Requirements

4. 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

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

6. 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

7. 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

8. 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

9. 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

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

11. 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

12. 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

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

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

15. 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

16. 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.

17. 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

18. 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

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

20. 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)

21. 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

22. 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.

23. 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

24. . 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

25. 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

26. 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.

27. 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.

28. 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. .

29. 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. • .

30. 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.

31. 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

32. Lesson Review • Objectives • 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

33. 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

34. 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

35. 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

36. 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

37. 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