I’ve written numerous posts on decision-to-requirements traceability based on the fact that decisions are the creators and consumers of requirements. Consistent with this, I use a 3V (or 3-Vee) model of traceability that is best represented by a 3-D model of 3 traceability Vee’s connected together.
If you’ve done quite a bit of systems engineering or new product development, you are likely familiar with the requirement-to-test/verification Vee. If you’ve read my blog, I may have also convinced you of the value of capturing the requirements derivation process at its source by managing both requirements-to-decision and decision-to-requirements traceability (the second Vee).
My purpose today is to stimulate you to take advantage of a third type of traceability relationship between decisions and tests (verification events). I believe this is low-hanging fruit that could be exploited by almost any organization. Think for a second – your organization almost certainly demands and provides a specific test or verification method for each product requirement. That means that you will be gathering product performance data (by direct test measurement or inspection, demonstration or simulation) that expresses how well your design satisfies each requirement. If your specification calls for a performance of >1.0 flibberwidgets/nanosecond, you will very likely do a decision analysis (trade study) early in the design process to estimate the effectiveness of various design alternatives. Your analysis (which may be done by an experienced-based paper estimate, extrapolating from similar designs, or running a simulation model) may estimate a value of 1.20 flibberwidgets/nanosecond, giving you a 20% design margin in your preferred solution. However, when you complete your testing, you may discover that the product only delivered 1.05 flibberwidgets/nanosecond; passing the spec limit, but much more narrowly than expected.
If you ignore the concept of decision-to-test traceability, you may miss a great opportunity here and stop at this point saying, “Whew, I’m sure glad we squeaked by on that one!” But there is free information staring you in the face at this point; you have a test result that reveals a 15% bias/error in the estimating technique that you used to inform your decision analysis/trade study. This is free knowledge at this point; you already paid for it to meet a product testing requirement. You can exploit it by asking, “What caused the bias in our estimating technique?” and “How can we improve our estimating technique so it will yield a better answer the next time we face this type of design decision?”
Learning organizations take full advantage of the knowledge they create to drive continuous process improvement. Start today by capturing your decision analyses and maintaining decision-requirements traceability. Then go a step further and improve the fidelity of your models by comparing your test results to your decision analysis predictions.
Filed under: Decision Concepts | Tagged: continuous improvement, decision analysis, derived requirements, design decisions, learning cycles, learning organizations, modeling, product development, requirements analysis, requirements derivation, requirements management, requirements traceability, systems engineering, test planning, trade study, V-model, Vee-model, verification | Leave a comment »