Perhaps I can help a little here, as there is some understandable confusion over how the F-35 programme's requirements process worked. Sorry if this repeats some of my earlier posts.
The F-35's requirements were developed over a period of many years from around 1994, via a document called the Joint Interim Requirements Document, the JIRD. As in any requirements document, there are two main types of things that drive its content.
First, what the user(s) want the system to do operationally. This is the stuff that pilots are comfortable with. However, it also needs to reflect such areas a logistics, personnel, etc. This will also include any hard constraints (e.g has to fit in a certain hangar)
The second, and less obvious area, is what the technology can deliver. Clearly, one can write a requirement asking for a Mach 5 jumbo with an invisibility cloak, but it's unlikely to be met. However, some level of technology risk will always have to be carried - you could write a very low risk requirement for an armed Chipmunk, but it might not be very effective. (I exaggerate to make my point here - sorry for that).
The operational side of the JIRD was built via a number of iterations (JIRD I, JIRD II...) using information gleaned from hundreds of scenario model events, war-games, and other studies. This process was rigorous, and subjected to external reviews and assessments. It was also internationally supported, and I know that some contributors to this thread were involved. (Not me, by the way). Experience from previous US use of LO aircraft was definitely factored in.
The technology side was guided by evidence from the UK/US ASTOVL work, plus US 'black programmes like SSF, and other (very) high level technology reviews and assessments. Key elements of that were engine performance targets and LO technology.
The end product of this was the JSF Joint Operational Requirements Document, the JORD. It was a fairly succinct document, given the size of the programme. It ran to around 160 discrete requirements, plus annexes, and was trying to reflect then current thinking on acquisition reform, particularly the need for the requirement to spell out 'what' was required, not 'how' to achieve it. The aim was to give the biggest possible 'trade space' for the designers to work in. The annexes gave some ground rules for interpreting and calculating performance against the requirements, plus key technical information on any constraints.
Key Performance Parameters (KPPs) were those requirements that were going to have the biggest impact on the overall system design. They were going to drive cost, and were absolutely vital to operational efficiency. In UK speak, they are KURs (Key user Requirements). And KPPs cannot be traded away without very high level attention. The small number of KPPs reflected the desire for a large trade space. There were just 19 in all, covering the three variants. The 'Joint' KPPs applied to all three variants and comprised RF signature, combat radius, SGR, Logs footprint, mission reliability and interoperability. The F-35B had two unique KPPs for STOVL TO distance and vertical lift bring back. The F-35C had a single KPP for approach speed to the carrier.
The JORD included other items such as turn rate, sustained g, key dimensions, key weapon loads and so on. However, as MSOCS has pointed out, these weren't KPPs, and were inside the anticipated 'trade space'.
Once the contract was awarded, LM began the job of taking the JORD and building the much (much) more detailed set of requirements that would be used for the design of the system. This process is sometimes called 'requirements management', and it's a systems engineering discipline. The result (for a complex job like F-35) is literally tens of thousands of requirements, usually built using database tools like DOORS. This, sadly, was an area where the LM team did not perform well. Instead of a disciplined (and long) process of building the requirements down from the top level JORD, in many cases LM teams, short of time, reached for existing specs, or were given 'requirements' by US military SMEs. In many cases, this worked OK. In some, it didn't.
In my view (alert - Engines opinion - not a fact) this was a major contributor to the weight crisis in 2004. The design was, in some areas, being driven by SME 'wants', not actual requirements 'needs'. I can't give details, but at some point in the future, there is a decent book (or PhD study) to be written on this angle of the programme. To this day, it's probably the source of much of the comment of the programme.
I hope that this has given some useful background on how requirements are supposed to work, and what KPPs are and aren't.
Best Regards as ever to those doing the requirements management task - thankless but essential,
Engines