द्विदिश ट्रेसबिलिटी अपनाएँ: हर महत्वपूर्ण आवश्यकता को उसे पूरा करने वाले निर्णयों और घटकों से जोड़ें, फिर उन घटकों को स्वीकृति के प्रमाण से जोड़ें। उल्टे लिंक बताते हैं कि कोई घटक क्यों मौजूद है और प्रस्तावित बदलाव किन आवश्यकताओं को प्रभावित कर सकता है।
छोटी, अद्यतन रखी गई कड़ी
text
[Requirement R-12] --> [Decision D-04] --> [Refund workflow]
| |
+--> [Acceptance test T-18] <-----------+
|
[Test evidence]
मान लें R-12 कहता है कि वही रिफंड अनुरोध दोहराने से दूसरा रिफंड नहीं बनना चाहिए। D-04 स्थिर व्यावसायिक ऑपरेशन पहचान और डुप्लिकेट पहचान चुनता है। वर्कफ़्लो इस नियम को लागू करता है। T-18 प्रतिक्रिया खोने का अनुकरण करने के बाद अनुरोध दोहराता है और सत्यापित करता है कि अभी भी केवल एक व्यावसायिक रिफंड है।