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

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

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

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

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

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

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

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

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

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