Requirements management,requirements traceability,requirements verification ... how can you measure if requirements are working for you?
In my travels among various industries, I look for metrics that can be used to measure the maturity level of requirements management, traceability and verification. They’re hard to find, but a recall or warranty issue certainly represents a missed or disconnected requirement. A maturity-type metric could be how long it takes for a problem once solved to come back.
For example, I talked to one young engineer who was assigned the task of tracking down a customer complaint about ‘water on the knee’. During the investigation she discovered water from inside the driver side door would come through the door speaker when the bass was turned up (we’ve all been pounded by the amped-up bass of a nearby vehicle’s woofers).
Looking inside the door, she found that water which should have drained harmlessly out of the weep holes in the bottom of the door was splashing up onto the speaker wire as it came down the door’s speaker wire conduit. Since the wire ran downhill, the water drops followed the wire down and into the speaker, leaving the bass vibrations to do the rest. Looking at the speaker wire’s revision history, she noted the previous revision wire had a loop held by a tie wrap. The loop naturally carried the water below the speaker.
Since there was no integrated requirements traceability, someone looking to save some money eliminated the extra 6 inches of wire. Looking at the previous version, the loop was there. The version before that the loop was gone again, and on ad infinitum. The wire was not only performing the function of delivering sound signal to the speaker, but was also performing the function or requirement of keeping water from getting into the speaker.
Some blame it on increasing government regulations and a litigious society, but that’s like your teenager blaming you for a ticket he got for his fender bender. There are many contributors, but a major factor is poor requirements verification practices disconnected from development processes that haven’t changed fast enough to keep up with increasing product complexity. These old processes allow mistakes to escape because they’re watching the wrong gates--typically the gates watch disciplines while most recalls are cross-discipline.
For example, the recent recall of an SUV due to drivers accidently turning off the motor when they meant to turn on/off the radio is typical. The buttons look alike and are too close to each other. It escaped notice because the ergonomics and electrical teams don’t sit near to each other, and even if they did, they speak different domain-specific languages. For example, if I say the word “bridge”. What do you think it means? It depends on your discipline; civil engineers think highway bridges, network engineers think network bridges, electrical engineers think Wheatstone bridges, dentists are thinking ‘bridge work’, and the list goes on. There are around 20 different definitions of bridge depending on the discipline.
One of the benefits of integrated requirements management and requirement traceability is to help ‘bridge’ these cross-domain definition issues—after all, requirements are the ultimate vocabulary that matters. Not only do the requirements represent the customer, they also represent an agreement between everyone involved on what a good design is and how you know when you’ve arrived; bridging the semantic gap between the silos.
Perhaps the most important benefit of integrated requirements management is leveraging your experiences. The problems you solve today expose requirements. Making sure they are traceable and verifiable helps ensure you don’t repeat them.
Until next time ...
About the blogger: Mark Sampson is the product manager/evangelist working on connecting requirements to the products they drive.