किसी बिज़नेस objective से लेकर टेस्ट तक traceability आप कैसे बनाए रखते हैं?

हर requirement को एक identifier दें और उसे ऊपर उस objective से जोड़ें जिसकी वह सेवा करती है और नीचे डिजाइन, बिल्ड आइटम और टेस्ट केस से। असली फायदा impact analysis है: जब देर से कुछ बदलता है, तो आप ठीक ठीक बता सकते हैं कि वह क्या क्या छूता है। matrix को हल्का रखें और जहां हो सके उसे तैयार करवाएं, क्योंकि हाथ से बनाए रखी गई matrix एक महीने में बासी हो जाती है।

हर requirement को एक identifier मिलता है, और वह ऊपर उस बिज़नेस objective से जुड़ती है जिसकी वह सेवा करती है और नीचे डिजाइन, story और टेस्ट केस से। मैं यह मेहनत कागजी कार्रवाई के लिए नहीं, impact analysis के लिए करता हूं। जब चौदहवें हफ्ते में कोई पूछता है कि अगर हम यह नियम हटा दें तो क्या होगा, तो मैं अंदाजा लगाने के बजाय दस मिनट में जवाब दे सकता हूं, और यह अकेले ही मेहनत को जायज ठहरा देता है। मैं इसे coverage के लिए भी इस्तेमाल करता हूं, तो acceptance testing में जाने से पहले मैं देख सकता हूं कि किन requirements के खिलाफ कोई टेस्ट नहीं है, और ऐसी कुछ हमेशा निकलती हैं। जरूरी बात यह है कि इसे सस्ता रखा जाए। अगर मैं spreadsheet हाथ से बनाए रखूंगा तो वह एक महीने में पुरानी पड़ जाएगी, इसलिए जहां भी टूलिंग story को requirement और टेस्ट से जोड़ने देती है वहां मैं वही इस्तेमाल करता हूं और matrix को एक रिपोर्ट बनने देता हूं। और मैं इसे घटाता बढ़ाता हूं: regulated प्रोग्राम पर पूरी traceability, दो महीने के internal बिल्ड पर कहीं हल्की।