They do to my wife. She recently received a recall notice in the mail on her car. It described how the weep holes in the moon roof can clog up causing rain water to spill into the vehicle leading to interior water damage. The notice included an updated page for the owner’s manual maintenance schedule that added a periodic check of the weep holes and an invitation to go to the nearest dealership for the needed maintenance. I went out and checked her cars weep holes; they were fine.
A few days later we received a legal notice in the mail asking if we wanted to be included in class-action lawsuit to compensate drivers for the personal damage caused by these plugged holes.
Given there were some 22 million of these recalls in the U.S. last year, I don’t think we are alone. In fact, you can try it yourself to see what recalls have been issued on your car by visiting the National Highway Traffic Administration website at www.NHTSA.gov. You will be surprised.
As you look at these recalls you will notice how many of them are about non-compliance to regulations/requirements. They are evidence of a lack of requirements management, requirements traceability, and requirements analysis. Others are emergent behaviors that come from consequences of complex systems interacting with each other, but that’s the topic for the Systems Engineering blog.
Of course it’s not just in automotive that this is going on. Food, energy, medical devices, and other industries have their own experiences. Some examples from recent headlines:
- Energy: BP found negligent for ignoring safety and reporting regulations of the Clean Water Act.
- Food/Beverage: Kraft recalls cheese as a precaution after supplier failed to store cheese according to standards.
- Medical Devices: FDA recalls largest number of devices ever after customer discovers packaging compromises resulting in loss of sterility.
I’m sure if we asked the manufacturers about managing requirements, almost all of them have some type of requirements management system (Excel, documents, databases, etc.) to control/manage requirements. But as these headlines attest, just managing requirements is not sufficient, it’s where the requirements go, what they impact that ultimately matters.
Thus the need to connect the requirements into the lifecycle—bring them into PLM where they can participate in the daily product development decisions to create ‘requirement compliant products’ and to ensure they are complied with/verified throughout the lifecycle (integrated requirements verification being the subject of another blog). It takes requirements management, requirements traceability, and requirements analysis.
With that background, you will see my blog articles from time to time exploring topics of requirements management, requirements traceability, and requirements analysis, including:
- Integrated requirement verification—start/stay verified thinking
- Before requirements—customer needs analysis and project scoping
- Using models as requirements—capturing the engineering behind the requirements
- Resilient systems design—designing robust products
- Integrated failure/risk management – requirements engineering and requirements analysis
- Culture/management thinking changes needed to move from late recall firefighting to early fire prevention thinking
… plus other requirements management and systems engineering topics. I hope you will join me for the ride.
About the blogger: Mark Sampson is the product manager/evangelist working on connecting requirements to the products they drive.