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

Taiga Learning · Worksheet अभ्यास पत्र
https://taiga.training/hi/lessons/specifications/

काल्पनिक या स्वीकृत जानकारी इस्तेमाल करें। इस worksheet में secrets न डालें।

## सीखने के उद्देश्य
- स्पष्ट सीमाओं के साथ जाँची जा सकने वाली requirement लिखें।
- Requirement को बदलाव और उसकी checks तक trace करें।
- बदली धारणा से प्रभावित बाद के documents पहचानें।

## अभ्यास
Manager के सक्रिय customers export करने की requirement लिखें। स्वीकार्य उपयोगकर्ता, organization सीमा, fields, failure का व्यवहार और मापी जा सकने वाली completion condition जोड़ें। काल्पनिक test और release से जोड़ें। फिर archived customers शामिल करने के लिए requirement बदलें और प्रभावित decisions लिखें।

## आपका उत्तर
- परिदृश्य और दायरा:
- धारणाएँ और खुले सवाल:
- प्रस्तावित उत्तर या निर्णय, कारणों सहित:

## अपना उत्तर सत्यापित करें
| दावा या मानदंड | प्रमाण या test | परिणाम या कमी | जिम्मेदार व्यक्ति |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## अगली कार्रवाई
- कार्रवाई, जिम्मेदार व्यक्ति और तारीख:
- आप इस उत्तर की समीक्षा कब करेंगे?

## याद रखने वाला सिद्धांत
Specification तब उपयोगी है जब उसके दावे decisions और सत्यापित किए जा सकने वाले व्यवहार से जुड़ें। System बदलने पर संबंध वर्तमान रखें।

## स्रोत
- [NIST: Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)
- [Google Engineering Practices: What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)

यह worksheet सीखने में मदद करती है। इसे पूरा करने से अपने-आप production में बदलाव की अनुमति नहीं मिलती।