Key Performance Parameters (KPP) are key system capabilities that must be met for a system to meet its operational goals set by the user/customer. These key capabilities form the foundation of any system and are deemed vital to its performance, function, design, and operations. Any changes to the KPP would have a significant impact on the performance of the system along with the development cost and schedule. That’s why they have been deemed the most important attributes of a system.
In the Defense Acquisition System, the Capability Development Document (CDD) and Capability Production Document (CPD) identify the KPP(s) that contribute to the desired operational capability in a threshold and objective format. Each KPP is supported by an operational analysis that considers technology maturity, fiscal constraints, and schedule before determining threshold and objective values. If an attribute is considered important but not critical to meeting system goals, it can be classified as a Key System Attribute (KSA).
Definition: Key Performance Parameters are attributes of a system considered critical to the development of an effective military capability. The number of KPPs identified by a Sponsor should be kept to a minimum to maintain program flexibility. Failure of a system to meet a validated KPP threshold/initial minimum rescinds the validation, brings the military utility of the associated system(s) into question, and may result in a reevaluation of the program or modification to production increments. 
See: Manual for the Operation of the JCIDS – Enclosure B, Appendix A
Key Performance Parameters (KPP) Values
A KPP or KSA’s threshold value is the minimum acceptable value considering cost, schedule, and technology. Performance below the threshold value is not operationally effective or suitable. A KPP also has an objective value that is the desired operational goal considering cost, schedule, and technology. Performance above the objective value does not justify the additional expense. The difference between the threshold and objective values sets the trade space.
- Threshold Value: an attribute is the “Minimum Acceptable Level” value considered achievable within the available cost, schedule, and technology at low-to-moderate risk.
- Objective Value: an attribute is applicable when a “Desired Level” of performance represents a significant increase in operational utility.
Key Performance Parameters (KPP) Validation
All KPPs and Key System Attributes (KSA) are validated by the Joint Requirement Oversight Council (JROC). Advances in technology or changes to system goals may result in changes to the KPP and KSA threshold and objective values, which will have to be validated by the JROC again. Below is the list of mandatory KPP that every system shall have according to the JCIDS Manual – Enclosure B (Appendix A).
Mandatory Key Performance Parameters (KPP) per para 2.5.4 2018 JCIDS Manual:
- System Survivability
- Force Protection
Key Performance Parameters (KPP) Development Steps: 
- Step 1: List required capabilities for each mission or function as described in the proposed CDD or CPD.
- Step 2: Review for applicability the list of attributes associated with each of the joint functions.
- Step 3: For each mission or function, build at least one measurable performance attribute using the list from Step 2 as a starting point.
- Step 4: Determine the attributes that are most critical or essential to the system(s) and designate them as KPPs.
- Step 5: Document how the KPPs are responsive to the capability performance attributes identified in the Initial Capability Documents (ICD)s in support of the mission outcomes and associated desired effects.
Guidelines for Identifying the Capstone Concepts Joint Operation (CCJO)-derived KPP:
- Based on the system’s primary mission, does it contribute to one or more of the CCJO characteristics of the future joint force? For example, a bomber could contribute to multiple key characteristics: expeditionary, adaptable, and enduring/persistent, and an unmanned aerial vehicle could contribute to knowledge-empowered, networked, and enduring/persistent.
- Does the system have other attributes that contribute significantly to any of the CCJO characteristics of the future joint force? For example, the tactical data link on a fighter may contribute to the overall networked characteristic and the primary mission of the fighter.
- If the answer is yes to either of the above, designate at least one (if not more) attribute as a KPP for each relevant characteristic. It is not necessary to designate as a KPP every attribute associated with a particular characteristic, only those most essential to the capability.
Difference Between a Key Performance Parameter (KPP) and Key System Attribute (KSA)
If an attribute is considered important but not critical to meeting system goals, it can be classified as a Key System Attribute (KSA). A KSA is a system capability considered crucial in support of achieving a balanced solution/approach to a Key Performance Parameter (KPP) or some other key performance attribute deemed necessary by the sponsor.
Requirements Development Steps
There is no set standard way to develop requirements but they are normally developed following the same basic six (6) steps. These requirements development steps don’t really change depending on which SE model is used. All models are similar in their approach but they just usually depict the step differently graphically. The main model that is used is the Systems Engineering “Vee” where requirements development is depicted on the left side.
Below is a list of the basic six (6) steps of requirements development.
- Overview: Requirements Development Steps
- Step 1: Gather and Develop Requirements
- Step 2: Write and Document Requirements
- Step 3: Check Completeness
- Step 4: Analyze, Refine, and Decompose Requirements
- Step 5: Verify & Validate Requirements
- Step 6: Manage Requirements
- KPP should be stated in terms that reflect the range of military operations that the capabilities must support and the joint operating environment intended for the system.
- When developing KPP’s, make sure that they are testable and how they should be tested. This is the only way to ensure that a system delivers the desired capability. Having untestable KPP on a program causes confusion and instability on a program. A verification cross-reference matrix is a good way to understand how a KPP, KSA, and other requirements will be tested.
- Keep the number of KPP’s to around 5. The more KPPs a program has the more performance, cost, and schedule instability.
AcqLinks and Resources:
- CJCS Instruction 3170.01 “Joint Capabilities Integration and Development System”
-  Manual for the Operations of the Joint Capabilities Integration and Development System (JCIDS)
- JCIDS Process Flow Chart