TPM is a sometimes elaborate process used to identify important quantitative technical characteristics and features of the system, and report them to management on a regular basis. For each characteristic, a plan is usually developed to show how its predicted (or estimated) value will improve over the course of development, and “trigger” values will be identified to indicate when the degree of management attention (frequency or detail in reporting) will change. The characteristics can include, but are not limited to, requirement topics.
I have always struggled with the concept of TPM. It seems to me that, if a technical characteristic is important enough to track, then a requirement should be written with respect to it. Conversely, if a characteristic is important enough to deserve a requirement, then this type of tracking should occur as a matter of course (centered on the Technical Reviews and Audits for each CI).
The TPM concept came into vogue not too long after we began to claim 100% requirements completion near the start of any given project, at which time we began “locking down” the requirements early by prohibiting subsequent changes. At about the same time, we saw a dramatic increase in the number of requirements written. I have always suspected that the relative timing of these three things was related: we write too many requirements because we’re afraid of leaving something out1, and we’re in a hurry…so we created a process off to the side that grabs just the important stuff.
Footnotes- Plus, some people just never met a requirement they didn’t like.[↩]