सॉफ्टवेयर विकास के लिए आवश्यकताओं को एकत्रित करने पर कुछ नोट्स

हाल ही में, मेरे एक दोस्त ने कुछ पेशेवर समुदायों में अंग्रेजी स्लैंग के प्रभुत्व के बारे में शिकायत की। मैंने उसे जवाब दिया कि यह बुरा था, लेकिन मजबूर किया गया। बस इसी तरह, प्राकृतिक उधार लेने की प्रक्रिया होती है, जहां आवश्यक को अनुकूलित किया जाता है और अनावश्यक बह जाता है। और अंग्रेजी भाषा में ही रूसी एंग्लिकिज़्म की तुलना में बहुत अधिक लैटिन हैं। आखिरकार, एक बार जो लोग विज्ञान में लगे हुए थे, उन्होंने विशेष रूप से लैटिन में संचार किया।

रूसी भाषा में, एक छोटा क्षेत्र बना हुआ है जहां इसे आधुनिक वास्तविकताओं में लाना आवश्यक है। यह लोगों और टीमों के प्रबंधन के क्षेत्र में पश्चिमी प्रथाओं पर लागू होता है। वे सोवियत विज्ञान द्वारा खराब अध्ययन किए गए थे, जबकि 90 के दशक में उनका त्वरित परिचय ऐसे लोगों द्वारा शुरू हुआ, जो हाल ही में उन्हें वैचारिक रूप से गलत मानते थे। तो यह अर्थव्यवस्था के साथ और अधिक विशिष्ट क्षेत्रों में था, जैसे कि सॉफ्टवेयर उत्पादन से संबंधित।
हम हमेशा जानते थे कि उत्कृष्ट प्रोग्राम कोड कैसे लिखा जाता है। लेकिन सॉफ्टवेयर व्यवसाय सरल काम पर रखा प्रोग्रामिंग की तुलना में व्यापक है - यह ज्ञान व्यापार है। और यदि ऐसा है, तो उत्पादन और उसके संगठन की आवश्यकता है। यहां, आवश्यकताओं को संग्रह प्रबंधन प्रणालियों द्वारा एक महत्वपूर्ण भूमिका निभाई जाती है, जहां उत्पादन प्रक्रिया को पश्चिमी अनुभव के आधार पर बनाया जाना है।

लेख में आगे कहा गया है कि कार्ल आई। विगर्स की पुस्तक "सॉफ्टवेयर रिक्वायरमेंट्स डेवलपमेंट" के अनुवाद से उदाहरणों का उपयोग करते हुए विशिष्ट उधार त्रुटियों का विश्लेषण किया जाता है। अंत में, चर्चा की गई सामग्री को सॉफ्टवेयर के लिए डिजाइन आवश्यकताओं के जीवन चक्र के वी-मॉडल का उपयोग करके संक्षेप में प्रस्तुत किया गया है।

निस्संदेह, कार्ल आई। विगर्स द्वारा "सॉफ्टवेयर आवश्यकताओं का विकास" (इसके बाद आरटीपीपीओ के रूप में संदर्भित) की एक उत्सुक पुस्तक रूसी सूचना समुदाय में एक निश्चित मानक बन रही है। लेकिन लेखक की अवधारणा के बाहर इस पुस्तक (उधार, मूल, अनुवादित) से प्रावधानों का उपयोग उन सवालों को उठाता है जिन्हें मैं समझना चाहता हूं।

यह आवश्यकताओं के विकास का एक चित्रण है क्योंकि परियोजना तीन दस्तावेजों के माध्यम से ऊपर से नीचे तक बढ़ती है: " परियोजना की छवि और सीमाओं पर दस्तावेज़ ", " उपयोग के मामलों पर दस्तावेज़ ", " सॉफ्टवेयर आवश्यकताओं की विशिष्टता "। तीसरे संस्करण में, पहले दो दस्तावेज़ " अवधारणा और सीमाओं के दस्तावेज़ " और " उपयोगकर्ता की आवश्यकताओं के दस्तावेज़ " के रूप में प्रस्तुत किए गए हैं।

सही दस्तावेज़ बनाने के लिए, आपको पहले इसके सार को समझना होगा। ऐसा लगता है कि कुंजी रहस्यमय " छवि और परियोजना की सीमाओं " को उजागर करने के लिए है : इसे हल किया है, और आप किसी भी प्रतिबंध के बिना और महान लाभ के साथ तैयार अभ्यास का उपयोग कर सकते हैं। दुर्भाग्य से, यह केवल तृतीय पक्षों से खरीदी गई सरल तकनीकों के साथ काम करता है। टीम प्रबंधन के पहलू सीधे एक विदेशी संस्कृति की विशेषताओं से संबंधित हैं , और वहां सब कुछ आसान नहीं है। सांस्कृतिक भिन्नता व्यवहार के अवचेतन जातीय रूढ़ियों के पूरे तंत्र के हिमखंड का दृश्यमान हिस्सा है। लेकिन हम अचेतन के दायरे को बिल्कुल भी नियंत्रित नहीं करते हैं, या हम केवल इसे आंशिक रूप से नियंत्रित करते हैं।

हालांकि, सब कुछ इतना निराशाजनक नहीं है। हमें अपने अभ्यास के साथ उनकी शब्दावली के संघों को खोजने की आवश्यकता है। हम " परियोजना की छवि और सीमाओं पर दस्तावेज़ " का विश्लेषण करेंगे। किसी प्रोजेक्ट की सीमाएँ प्रोजेक्ट स्कोप हैं । इसका अनुवाद " कार्यभार " के रूप में किया जाना चाहिए। शब्दकोश में नहीं? अफसोस। आप अंग्रेजी नियमावली: प्रोजेक्ट स्कोप - प्रोजेक्ट प्लानिंग का एक हिस्सा देख सकते हैं , जिसमें प्रोजेक्ट के निर्धारित लक्ष्यों, परिणामों, कार्यों, लागतों और समय-सीमा को निर्धारित करने की प्रक्रिया शामिल है । एक विशिष्ट प्रक्रिया है, इसे " परियोजना की सीमाएं " क्यों नहीं कहा जाता है? इस मामले में, हमारे अपने पिछले अनुभव के एकीकरण के साथ समस्याएं उत्पन्न होंगी: आखिरकार, हम पहले काम की गुंजाइश का निर्धारण करते हुए, विशेष रूप से योजना बना रहे हैं।

जब शब्दकोश अनुवाद विफल हो जाता है, तो आपको एक साधारण वैचारिक मॉडल की तलाश करनी होगी जो संबंधित विषय क्षेत्र में विवादास्पद शब्द के उपयोग को दिखाता है। देशी मिट्टी के प्रकटीकरण के इस तरह के एक सरल मॉडल के आगे स्थानांतरण से हमें भाषा मैच खोजने की अनुमति मिलती है। ट्रिपल बाधा मॉडल परियोजना प्रबंधन का एक परिचय है।

यह मॉडल " निष्पादन समय ", " लागत ", " कार्य की मात्रा " (समय, लागत, गुंजाइश) के बीच संबंधों को प्रकट करता है, जो एक समबाहु त्रिकोण के रूप में रखा जाता है, जिसका अर्थ है कि इस त्रिभुज के एक तरफ बदलने से सभी में बदलाव होता है।

प्रोजेक्ट विज़न को कभी-कभी " प्रोजेक्ट इमेज " के रूप में नहीं, बल्कि " प्रोजेक्ट कॉन्सेप्ट " के रूप में अनुवादित किया जाता है, लेकिन यह स्पष्टता नहीं जोड़ता है। हैंडबुक में प्रोजेक्ट विज़न स्टेटमेंट को " व्यवसाय के सफल समापन पर प्राप्त किए जाने वाले वांछित व्यावसायिक परिणामों का एक आदर्शवादी दृष्टिकोण " के रूप में परिभाषित किया गया है । हम आमतौर पर " परियोजना के उद्देश्यों " शब्द का उपयोग करते हैं और घरेलू निराशावाद के हिस्से के साथ इन कार्यों को तैयार करते हैं। यदि हम इसे " परियोजना की छवि " कहते हैं, तो यह संभावना नहीं है कि यह अपनी धरती पर पश्चिमी आशावाद को प्रकट करने में मदद करेगा। कुल मिलाकर, पहले दस्तावेज़ को " प्रोजेक्ट ऑब्जेक्टिव्स एंड स्कोप ऑफ़ वर्क " कहा जा सकता है। और कुछ भी रहस्यमय नहीं है।

यह माना जाता है कि ऐसे शब्दों का अनुवाद नहीं किया जाना चाहिए, लेकिन परियोजना में अंग्रेजी भाषा का उपयोग करें। यह केवल भाग में काम करता है, उन लोगों के चक्र को सीमित करता है जो मामलों में विशेषज्ञ हैं। बुनियादी भाषा कौशल पर्याप्त नहीं हैं जहां तकनीकी मुद्दे जातीय-सांस्कृतिक अंतर से संबंधित हैं।

यहां RTkPO से एक विशिष्ट उदाहरण है: " आवश्यकताओं को क्रमिक रूप से कहा जाना चाहिए, उदाहरण के लिए," सिस्टम होगा ... "या" उपयोगकर्ता होगा ... ", फिर सक्रिय क्रिया, और फिर मनाया परिणाम ... आप" का उपयोग कर सकते हैं "चाहिए" के लिए एक पर्याय के रूप में ", लेकिन "चाहिए", "हो सकता है", "हो सकता है" और इसी तरह के शब्दों से बचें, जिससे यह स्पष्ट नहीं है कि क्या कार्रवाई आवश्यक है । "
आप सोच सकते हैं कि यह कार्रवाई के लिए तैयार गाइड है। वास्तव में, यह अनुवाद यह पता लगाने में मदद नहीं करता है, लेकिन यह सब कुछ और भी अधिक भ्रमित करता है। इसके अलावा, अंग्रेजी मूल अंतिम सत्य नहीं है, लेकिन अंग्रेजी भाषा की आधुनिकता पर एक निश्चित दृष्टिकोण की अभिव्यक्ति है। यह दृश्य RFC2119 ** मानक में निहित है, जो आवश्यकताओं के प्रबंधन के क्षेत्र में अंग्रेजी कीवर्ड का उपयोग करने के नियमों को स्पष्ट करता है ( जैसे, चाहिए, चाहिए, हो सकता है )। उदाहरण के लिए, इस मानक में, का अर्थ " यह है कि परिभाषा विनिर्देश की पूर्ण आवश्यकता है ।" हालांकि, लेखक को आवश्यक उपयोग के साथ प्रत्यक्ष निषेध के साथ दस्तावेज़ टेम्पलेट मिले (इस स्थिति का स्पष्टीकरण इंटरनेट *** पर उपलब्ध है)।

आवश्यकताओं के लिए विवरण का अगला स्तर " केस केस का उपयोग करें " है। RTkPO में, यह इंगित किया गया है कि यह उपयोग के मामलों, परिदृश्यों और घटना-प्रतिक्रिया तालिकाओं को परिभाषित करता है। " मामलों का उपयोग करें " के रूप में " मामलों का उपयोग करें " का अनुवाद अनावश्यक रूप से चीजों के दृष्टिकोण को सरल करता है (इसलिए, व्यवहार में, उपयोगकर्ता मामलों का अंग्रेजीवाद अधिक मजबूती से स्थापित हो गया है)। आधुनिक सॉफ्टवेयर में हैकिंग से सुरक्षा और मूर्ख से सुरक्षा होनी चाहिए, लेकिन इसे रूसी भाषा के खिलाफ हिंसा - उपयोग के लिए एक विकल्प पर विचार करें। अनुवाद के लिए, "सहभागिता परिदृश्य" प्रस्तावित हैं।

वास्तव में, घटना-प्रतिक्रिया मॉडल हमें ज्ञात है। हाई स्कूल में, इसे " प्रभाव - ^उतार - ^{चढ़ाव} -> प्रतिक्रिया " के रूप में अध्ययन किया जाता है। उसी प्रभावों के तहत, यादृच्छिक उतार-चढ़ाव के कारण प्रणाली की प्रतिक्रिया भिन्न हो सकती है। उपयोगकर्ता सॉफ़्टवेयर में, ये आमतौर पर विभिन्न त्रुटि स्थितियां होती हैं। इसके अतिरिक्त, अवधारणा स्तर पर, पर्यावरणीय प्रभावों को उपयोगकर्ता प्रभावों से अलग किया जाना चाहिए। आवश्यकताओं के इस स्तर के लिए एक अधिक या कम उपयुक्त नाम " सिस्टम आवश्यकताएँ " या पहले से ही " सॉफ़्टवेयर उत्पाद आवश्यकताएँ " है, हालांकि शब्दावली स्थापित नहीं की गई है और बहुत भिन्न विकल्प सामने हैं (उदाहरण के लिए, नवीनतम संस्करण में " उपयोगकर्ता आवश्यकताएँ दस्तावेज़ " नाम का उपयोग किया जाता है, जो स्वचालित रूप से होता है) विचार से एम्बेडेड सिस्टम को बाहर करता है)।

इस स्तर की आवश्यकताओं को विकसित करने का सार सॉफ्टवेयर का एक विस्तृत सट्टा मॉडल का निर्माण है जो एक आदर्श बाहरी दुनिया में कार्य करता है। इसलिए, एक महत्वपूर्ण बिंदु सीमा निर्धारित कर रहा है और धारणाएं बना रहा है। " कार का रंग कोई भी हो सकता है, बशर्ते कि यह काला हो, " - इसलिए हेनरी फोर्ड ने कार के रंग के लिए व्यावसायिक आवश्यकता को एक धारणा में बदल दिया। हालांकि, एक और समय, कार की सफाई के लिए व्यावसायिक आवश्यकता को पूरा करने के लिए, गैर-प्लानर सुव्यवस्थित ग्लास बनाने के लिए आवश्यक निकला। फोर्ड इंजीनियरों ने कहा कि यह तकनीकी रूप से असंभव था। फोर्ड को युवा आविष्कारक मिल गए।

निचले स्तर का प्रतिनिधित्व " सॉफ़्टवेयर आवश्यकताएँ विशिष्टता " द्वारा किया जाता है, जिसमें " प्रतिबंध ", " बाहरी इंटरफ़ेस ", " गुणवत्ता गुण " और वास्तव में " कार्यात्मक आवश्यकताएं " शामिल हैं। यह आंकड़ा का अंतिम दस्तावेज है, दुर्भाग्य से, बाद के परीक्षण के प्रश्नों को संबोधित नहीं किया गया है। इसलिए, परिभाषा तैयार करने के लिए, RTkPO को व्यावसायिक आवश्यकताओं की अवधारणा का उपयोग करने के लिए मजबूर किया जाता है: " कार्यात्मक आवश्यकताएं सॉफ्टवेयर कार्यक्षमता निर्धारित करती हैं जो डेवलपर्स को बनाना चाहिए ताकि उपयोगकर्ता व्यावसायिक आवश्यकताओं के ढांचे के भीतर अपने कार्यों को पूरा कर सकें "

परीक्षण पक्ष पर, निर्माण करने के लिए परिभाषा सरल है: " कार्यात्मक आवश्यकताओं की आवश्यकताएं हैं जिनका परीक्षण किया जा रहा है ।" इसे शास्त्रीय अर्थों में एक परीक्षण के साथ प्रत्येक कार्यात्मक आवश्यकता का परीक्षण करने की क्षमता के रूप में समझा जाना चाहिए (फैसले के साथ - पारित या असफल)। दृढ़, कड़ाई से बोलना, सच नहीं है: कुछ परीक्षण अपने आप ही मौजूद हो सकते हैं। लेकिन इस तरह के परीक्षणों की उपस्थिति आवश्यकताओं पर काम में चूक का एक संकेतक है। आखिरकार, परीक्षण कोड के किसी भी हिस्से की जांच करता है जो अपने आप नहीं दिखाई दिया, लेकिन एक निश्चित कार्यात्मक आवश्यकता के निष्पादन के परिणामस्वरूप।

आधुनिक परिपक्व सॉफ्टवेयर विकास प्रक्रियाएं सॉफ्टवेयर उत्पाद निर्माण के शुरुआती चरणों में मापक घटक लाने की कोशिश कर रही हैं। विवरण में जाने के बिना - अधिकांश भाग के लिए ये सभी प्रकार के कवरेज मीट्रिक हैं। भविष्य के उत्पाद की गुणवत्ता के संकेतकों में से एक कार्यात्मक आवश्यकताओं के परीक्षण के साथ कवरेज का प्रतिशत है, जो कि कवरेज की तालिका (मैट्रिक्स) (ट्रेसबिलिटी मैट्रिक्स) का उपयोग करके गणना की जाती है। मैट्रिक्स में एक गैर-कार्यात्मक आवश्यकता को शामिल करना संभव है, लेकिन भविष्य के काम में इसे सबसे अस्थिर के रूप में चिह्नित किया जाएगा, और, सबसे महत्वपूर्ण बात, परीक्षक इसे बेकार के रूप में मूल्यांकन करेंगे। ऐसा लगता है कि गैर-कार्यात्मक आवश्यकताओं की एक सूची के साथ " सॉफ्टवेयर आवश्यकताओं का एक पूरा विनिर्देशन " प्रोग्रामर के लिए बहुत उपयोगी है। और यह, शायद, ऐसा होगा यदि, संकलन के बाद, उन्होंने वहां देखा, कम से कम समय-समय पर।

गैर-कार्यात्मक आवश्यकताओं के विशाल बहुमत को कार्यात्मक तरीके से लिखा जा सकता है। विरोधाभास के लिए, सिस्टम या सॉफ़्टवेयर उत्पाद के लिए लगभग किसी भी गैर-कार्यात्मक आवश्यकता को एक या अधिक कार्यात्मक आवश्यकताओं में संसाधित किया जा सकता है।
RTkPO में गुणवत्ता की विशेषताएं आंशिक रूप से कार्यात्मक आवश्यकताओं में आती हैं, जो बिल्कुल सच है। हालाँकि, RTkPO की सीमाओं और बाहरी इंटरफ़ेस को निम्नानुसार परिभाषित किया गया है: “ अन्य गैर-कार्यात्मक आवश्यकताएं सिस्टम और बाहरी दुनिया के बीच बाहरी बातचीत, डिजाइन और कार्यान्वयन प्रतिबंधों का वर्णन करती हैं। "बाधाएं (बाधाएं) उत्पाद की उपस्थिति और संरचना के विकास की संभावना के चुनाव से संबंधित हैं ।" बाहरी दुनिया के साथ संचार उप-प्रणालियों में हमेशा एक इंटरफ़ेस होता है जो कार्यात्मक होता है और परीक्षण के अधीन होता है।

क्या प्रतिबंध कार्यात्मक आवश्यकताएं हो सकती हैं? निश्चित रूप से हाँ, यदि आप उन्हें उल्टे रूप में अवसरों के रूप में लिखते हैं। उदाहरण के लिए, उत्पाद प्रतियोगियों की तुलना में तेज होना चाहिए (अन्यथा इसकी आवश्यकता नहीं है - एक बहुत गंभीर प्रतिबंध)। सबसे पहले, हम आवश्यकताओं के रूप में, किए गए निर्णयों की नवीनता के बारे में बात कर रहे हैं। लेकिन यह स्पष्ट है कि सिस्टम में इस गति के ज्ञात मापदंडों को मापने के लिए एक मॉड्यूल होना चाहिए, और एक प्रारंभिक चरण में।

तो, " फंक्शनल स्पेसिफिकेशन्स " एक प्रारूपित दस्तावेज़ के रूप में या विशेष सॉफ़्टवेयर के नियंत्रण में डेटाबेस के रूप में निचले स्तर के विनिर्देशों के लिए एक स्थापित नाम है।

आगे आवश्यकताओं का क्या होता है? डेवलपर्स (प्रोग्रामर) के अलावा, परीक्षण इंजीनियर और क्यूए (गुणवत्ता आश्वासन) इंजीनियर आवश्यकताओं के साथ काम करेंगे। "परीक्षण" का अनुवाद "सत्यापन" के रूप में किया जा सकता है, लेकिन उधार "परीक्षण" स्पष्ट रूप से हुआ। क्यूए का अनुवाद करने के लिए फिर से एक प्रकटीकरण मॉडल की आवश्यकता है - यहां, कौन से सिद्धांत इसे रेखांकित करते हैं। सबसे पहले, " उद्देश्य के लिए फिट " (उत्पाद को इच्छित उद्देश्य के लिए उपयुक्त होना चाहिए), दूसरे, " सही पहली बार " ("पहली बार" - त्रुटियों को समाप्त किया जाना चाहिए) और तीसरा, परियोजना स्वतंत्रता। यह " स्वीकृति " है, सिद्धांत प्रसिद्ध सैन्य स्वीकृति और पौराणिक राज्य स्वीकृति को रेखांकित करते हैं।

आवश्यकता विनिर्देशन आगे के डिजाइन दस्तावेजों का आधार बनेंगे। कम से कम, आवश्यकताओं का उपयोग उपयोगकर्ता प्रलेखन के विकास में किया जाएगा। यह आमतौर पर स्वीकार किया जाता है कि परीक्षण एक परीक्षण योजना के साथ शुरू होता है और एक परीक्षण रिपोर्ट के साथ समाप्त होता है - सीधे विनिर्देशों से संबंधित दस्तावेज। आरटीपीपीओ में आंकड़े को अलग तरह से देख सकते हैं - सॉफ्टवेयर विकास प्रक्रिया (या एक सॉफ्टवेयर जीवन चक्र मॉडल) के सामान्यीकृत मॉडल के रूप में। इस मॉडल में, तैयार दस्तावेज प्रक्रिया के चरणों के बीच प्रवेश / निकास बिंदु हैं।

कालानुक्रमिक क्रम में, दस्तावेज़ निम्नानुसार प्रस्तुत किए जाएंगे: व्यावसायिक आवश्यकताएं (परियोजना क्षेत्र के हिस्से के रूप में), सिस्टम आवश्यकताएँ (पीओ), कार्यात्मक आवश्यकताएं, परीक्षण योजना, परीक्षण रिपोर्ट, उपयोगकर्ता प्रलेखन। दो दस्तावेजों के बीच की प्रक्रिया प्रक्रिया का चरण है। मॉडल अक्सर चक्र या सर्पिल को दोहराने के रूप में तैयार किए जाते हैं, हालांकि, एक साधारण कालानुक्रमिक अक्ष अधिक दिखाई देता है। फिर प्रक्रिया का पहला और अंतिम चरण एक खंड द्वारा नहीं, बल्कि एक किरण द्वारा इंगित किया जाता है। आधुनिक प्रस्तुतियों में, समय अक्ष " V " अक्षर के रूप में कोडिंग चरण के बीच में मुड़ा हुआ है, तथाकथित वी-मॉडल प्राप्त कर रहा है ।



धराशायी लाइनें कालानुक्रमिक अक्ष को दरकिनार करते हुए कनेक्शन दिखाती हैं, जो पहले से कुछ काम शुरू करने की क्षमता दिखाती है। उदाहरण के लिए, तैयार की गई व्यावसायिक आवश्यकताओं के साथ, आप पहले से ही उत्पाद के उपयोगकर्ता प्रलेखन के बारे में कुछ कह सकते हैं, और सिस्टम के लिए गठित आवश्यकताएं भविष्य के सॉफ़्टवेयर का एक मॉडल देगी, जिसकी गुणवत्ता का पहले से ही मूल्यांकन किया जा सकता है।

लेकिन इन पंक्तियों का मुख्य कार्य वी-मॉडल की स्केलेबिलिटी (सरलीकरण) को दिखाना है। सभी चरणों और दस्तावेजों का समर्थन करना हमेशा एक महंगी खुशी है, और अधिक मोबाइल प्रतियोगियों को खोने का एक बहुत ही सामान्य कारण है । उदाहरण के लिए, एक व्यक्ति इस तरह काम करता है: व्यावसायिक आवश्यकताएं -> विकास (कोडिंग) -> उपयोगकर्ता प्रलेखन। यह कट की ऊपरी टूटी हुई रेखा है। आउटसोर्सिंग कंपनियां, एक नियम के रूप में, कार्यात्मक विनिर्देशों पर पैसा खर्च किए बिना निचले चरणों को छोड़ देती हैं और एक या दूसरे प्रकार की सिस्टम आवश्यकताओं (उदाहरण के लिए, इंटरैक्शन परिदृश्य ) द्वारा सीमित होती हैं। एक ही प्रकार के उत्पादों के लिए, आमतौर पर एक उद्यम मानक होता है, और कोडिंग चरण से क्यूए / स्वीकृति चरण शुरू करने के लिए डेवलपर्स के आंतरिक परीक्षण की एक निश्चित रिपोर्ट जारी की जाती है।

मौलिक वी-मॉडल जिम्मेदारी के क्षेत्रों को स्पष्ट करने में मदद करता है। उदाहरण के लिए, एक कर्मचारी स्वीकृत इंजीनियर (QA) या टेस्ट इंजीनियर की भूमिका निभाता है, उस चरण पर निर्भर करता है जिसमें वह काम करता है। इससे कोई फर्क नहीं पड़ता कि उसे किसी विशिष्ट परियोजना या विभाग को सौंपा गया है। विश्लेषक, डिजाइनर, डेवलपर के लिए भी यही बात लागू होती है - एक व्यक्ति द्वारा इन सभी भूमिकाओं को पूरा करने की क्षमता वी-मॉडल का खंडन नहीं करती है। स्वीकृति अभियंता (QA) और विश्लेषक के लिए आधार "सिस्टम आवश्यकताएँ" है, वे एक ब्लैक बॉक्स के रूप में विकसित सॉफ्टवेयर के साथ काम करते हैं। चरणों में शामिल लोगों के लिए, डिजाइन, विकास और परीक्षण एक सफेद बॉक्स है, जो एक अलग सीमा तक है।

अंत में, यह ध्यान देने योग्य है कि वी-मॉडल अभी भी प्रस्तुति है (इस मामले में, आवश्यकताओं के डिजाइन विकास को दर्शाता है)। यह कार्रवाई के लिए प्रत्यक्ष मार्गदर्शक नहीं है; वास्तविक सॉफ्टवेयर विकास प्रक्रियाएं अधिक जटिल हैं। लेकिन इसकी खुलासा करने की क्षमता को कम करके समझना मुश्किल है।

---

* कार्ल आई। विगर्स "सॉफ़्टवेयर आवश्यकताएँ विकास।"
** RFC में उपयोग के लिए मुख्य शब्द आवश्यकता स्तर को इंगित करने के लिए (https://tools.ietf.org/html/rfcn111111)
*** अवश्य - उपयोग नहीं करना चाहिए क्योंकि किसी ने परिभाषित नहीं किया है कि कैसे अलग होना चाहिए। इसके अलावा, अदालत में आयोजित किया गया है, नहीं होना चाहिए। दी, लगता है मजबूत होना चाहिए, है ना? मेरा मतलब है, अगर आपका बॉस आपसे कहता है कि आपको कुछ करना चाहिए, तो आप इसे करने जा रहे हैं। लेकिन, आवश्यकताएं लिखते समय, चीजों को सरल रखें और बस उपयोग करें (http://www.reqexperts.com/blog/2012/10/use-the-correct-terms-shall-will-should)