When Good Requirements Turn Bad

When the end-user requires a specific reliability for a system (whether it is Operational MTBF, Mission Reliability, or some other relevant metric), he/she does not ultimately care what the root failure cause is. The loss of mission capability, inadequate availability, or deficiencies in the supply chain can (and will) be attributable to a combination of inherent hardware and other non-hardware root failure causes that will determine how well (or poorly) a system meets end-user requirements for performing or completing a mission. This paper describes how bad requirements can evolve, beginning with the end-users' stated reliability needs and their subsequent translation into contractual reliability requirements. This evolution is discussed in the context of its impact on the system engineering design process, its influences on the reliability prediction process, and its ultimate negative effects on (and increased risks associated with) the development of reliability growth curves and statistically relevant reliability test plans. The paper then presents a recommended process for developing realistic reliability requirements that (1) are based on stated operational reliability needs, (2) comprehensively address both hardware and non-hardware failure categories, and (3) do not rely on the limited coverage of empirical and physics-based prediction approaches. The paper also recommends forward-looking improvements to how reliability test and field data should be collected, analyzed to root failure cause and categorized to accommodate this new reliability requirements development process.