Software बदलने पर requirements की traceability बनाए रखें

ऐसा व्यवहार बताएँ जिसे कोई जाँच सके

“आधुनिक customer export बनाएँ” महत्वपूर्ण decisions खुले छोड़ता है। इसमें users, records, fields या failure का व्यवहार तय नहीं है। Agent को पूछना होगा या धारणाएँ बनानी होंगी। दर्ज न की गई धारणाओं का बाद में review कठिन होता है।

स्पष्ट सीमा वाली काल्पनिक requirement लें: authenticated manager अपनी organization के सक्रिय customers export कर सकता है। Export में customer ID और display name होते हैं। Contact details और archived records बाहर रहते हैं। Manager role के बिना उपयोगकर्ता को export नहीं मिलता।

अभी भी format, volume, response time और failure handling के decisions चाहिए। अज्ञात बातें स्पष्ट चिह्नित करें। उपयोगी specification अनिश्चितता को आत्मविश्वास वाले वाक्यों में छिपाने के बजाय दिखाती है।

Requirements और implementation choices अलग रखें

उपयोगकर्ता को इस्तेमाल किए जा सकने वाले format में स्वीकार्य records चाहिए। Database query, library और endpoint की संरचना implementation choices हैं। हर वर्तमान choice को स्थायी business need माने बिना उन्हें requirement से जोड़ें।

असर वाला decision उसके context, alternatives और कारण के साथ दर्ज करें। उदाहरण के लिए, synchronous export कम data volume के लिए उपयुक्त हो सकता है। अधिक volume पर background job और download authorization की अलग check चाहिए हो सकती है।

जहाँ संभव हो requirement स्थिर रखें, जबकि बदले decision का नया version रखें। इससे reviewer अलग implementation और उपयोगकर्ता से अलग वादे का अंतर कर सकता है।

प्रमाण की छोटी शृंखला बनाएँ

ऐसे identifiers इस्तेमाल करें जो reviews में समझ आएँ। इस उदाहरण में EXPORT-01 organization की सीमा पहचान सकता है। नाम उदाहरण है, जरूरी numbering system नहीं।

शृंखला को वास्तविक प्रमाण तक पहुँचना चाहिए। Test के नाम में requirement ID होने से यह सिद्ध नहीं होता कि assertion उसे जाँचता है। Test और जिस production path को वह परखता है, उसका निरीक्षण करें।

NIST का SSDF सुरक्षित development में requirements और verification का संदर्भ देता है। केवल documentation बनाने के लिए लिखने के बजाय, इन कामों को जाँचने योग्य बनाने में traceability का उपयोग करें। Framework पढ़ें।

बदली धारणा का असर जाँचें

मान लें business को अब archived customers भी चाहिए। इस बदलाव का असर query flag से अधिक है। Retention rules, authorization, अपेक्षित volume, उपयोगकर्ताओं को दिए स्पष्टीकरण और मौजूदा reports का अर्थ जाँचें।

प्रभावित documents और checks को review के लिए चिह्नित करें। पिछला decision बनाए रखें, ताकि operator पुराना release समझा सके। नवीनतम design को पहले से तय एकमात्र विकल्प दिखाने के लिए चुपचाप इतिहास न बदलें।

Agent references ढूँढ़ने और updates सुझाने में मदद कर सकता है। जिम्मेदार लोगों को विरोधी requirements हल करनी हैं और बदला व्यवहार स्वीकार करना है। मेल खाती files की सूची शुरुआत है, पूरे असर का आकलन नहीं।

Record को उपयोग लायक छोटा रखें

Implementation, verification और संचालन को प्रभावित करने वाले decisions दर्ज करें। कई असंबद्ध documents में वही requirement दोहराने से बचें। एक maintained source के links को प्राथमिकता दें।

बदलाव स्वीकार करने से पहले पूछें कि reviewer उसका उद्देश्य वास्तविक प्रमाण तक trace कर सकता है या नहीं। उसे चलाने से पहले पूछें कि service का जिम्मेदार व्यक्ति संबंधित सीमा और recovery decision ढूँढ़ सकता है या नहीं। ये उपयोगी traceability की व्यावहारिक जाँच हैं।