आवश्यकताएँ इंजीनियरिंग
आवश्यकताएँ इंजीनियरिंग एक सॉफ्टवेयर सिस्टम को क्या करना चाहिए और किन बाधाओं के तहत उसे संचालित होना चाहिए, इसकी खोज, विश्लेषण, दस्तावेजीकरण, सत्यापन और प्रबंधन का अनुशासन है।
Definition
आवश्यकताएँ इंजीनियरिंग एक सॉफ्टवेयर सिस्टम द्वारा प्रदान की जाने वाली सेवाओं और उसके संचालन और विकास पर बाधाओं को जानने, विश्लेषण करने, निर्दिष्ट करने, मान्य करने और प्रबंधित करने की व्यवस्थित प्रक्रिया है।
Scope
यह क्षेत्र हितधारकों की आवश्यकताओं को जानने; परस्पर विरोधी लक्ष्यों का विश्लेषण और बातचीत करने; कार्यात्मक और गैर-कार्यात्मक (गुणवत्ता) आवश्यकताओं के बीच अंतर करने; प्राकृतिक-भाषा कथनों से लेकर औपचारिक मॉडल तक की विशिष्टता तकनीकों; समीक्षा और प्रोटोटाइपिंग के माध्यम से सत्यापन; और जीवन चक्र में आवश्यकताओं के परिवर्तनों और पता लगाने की क्षमता के प्रबंधन को शामिल करता है।
Sub-topics
Core questions
- हितधारकों की वास्तविक आवश्यकताओं को कैसे खोजा और स्पष्ट किया जाता है?
- कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं को सटीक लेकिन समझने योग्य तरीके से कैसे निर्दिष्ट किया जाना चाहिए?
- आपसी विरोधी आवश्यकताओं का पता कैसे लगाया जाता है, उन पर बातचीत कैसे की जाती है और उन्हें कैसे सुलझाया जाता है?
- आवश्यकताओं को कैसे मान्य किया जाता है और बदलते रहने पर उन्हें सुसंगत कैसे रखा जाता है?
Key theories
- कार्यात्मक बनाम गैर-कार्यात्मक आवश्यकताएँ
- आवश्यकताओं को कार्यात्मक कथनों में विभाजित किया जाता है कि सिस्टम को क्या करना चाहिए और गैर-कार्यात्मक (गुणवत्ता) बाधाओं जैसे प्रदर्शन, सुरक्षा और उपयोगिता जो अक्सर पूरे सिस्टम में फैली होती हैं और वास्तुकला को संचालित करती हैं।
- लक्ष्य-उन्मुख आवश्यकताएँ इंजीनियरिंग
- सिस्टम का विश्लेषण हितधारक लक्ष्यों के संदर्भ में किया जाता है जिन्हें उप-लक्ष्यों में परिष्कृत किया जाता है और आवश्यकताओं में परिचालित किया जाता है, जो उच्च-स्तरीय इरादे से सिस्टम कार्यों तक तर्क, संघर्ष का पता लगाने और पता लगाने की क्षमता प्रदान करता है।
Clinical relevance
आवश्यकताओं की त्रुटियाँ सबसे महंगी दोषों में से हैं क्योंकि वे डिज़ाइन और कोड में फैल जाती हैं; कठोर आवश्यकताओं की इंजीनियरिंग पुनरावृत्ति को कम करती है, वितरित सॉफ्टवेयर को हितधारक की आवश्यकताओं के साथ संरेखित करती है, और स्वीकृति परीक्षण और संविदात्मक समझौते के लिए आधार प्रदान करती है।
Evidence & guidelines
ISO/IEC/IEEE 29148 आवश्यकताओं की इंजीनियरिंग प्रक्रियाओं और आवश्यकताओं के विनिर्देशों की सामग्री को निर्दिष्ट करता है, और SWEBOK सॉफ्टवेयर आवश्यकताएँ ज्ञान क्षेत्र एक आम सहमति संदर्भ प्रदान करता है।
History
आवश्यकताएँ इंजीनियरिंग 1970 के दशक की संरचित-विश्लेषण विधियों से विकसित होकर 1990 के दशक में एक मान्यता प्राप्त उप-अनुशासन बन गई, जिसे समर्पित सम्मेलनों (RE) और पत्रिकाओं, लक्ष्य- और परिदृश्य-आधारित मॉडलिंग के उदय, और गैर-कार्यात्मक आवश्यकताओं और हितधारक वार्ता पर बढ़ते ध्यान से चिह्नित किया गया।
Debates
- पहले से बनाम उभरती हुई आवश्यकताएँ
- योजना-संचालित अभ्यास निर्माण से पहले आवश्यकताओं को अच्छी तरह से निर्दिष्ट करने का पक्षधर है, जबकि फुर्तीला अभ्यास आवश्यकताओं को उभरती हुई और पुनरावृति के माध्यम से परिष्कृत मानता है; व्यापार-बंद अस्थिरता, संविदात्मक बाधाओं और देर से परिवर्तन की लागत पर निर्भर करता है।
Key figures
- Axel van Lamsweerde
- Bashar Nuseibeh
- Steve Easterbrook
- Michael Jackson
Related topics
Seminal works
- vanlamsweerde2009
- nuseibeh2000
- sommerville2015
Frequently asked questions
- आवश्यकताओं की त्रुटियाँ इतनी महंगी क्यों होती हैं?
- एक गलत समझी गई या अनुपलब्ध आवश्यकता अक्सर देर से ही पता चलती है, जब उस पर डिज़ाइन और कोड बन चुका होता है, इसलिए इसे ठीक करने के लिए बाद के काम को पूर्ववत करना पड़ता है; अनुभवजन्य अध्ययन लगातार दिखाते हैं कि दोष को ठीक करने की लागत जितनी देर से पाई जाती है, उतनी ही तेजी से बढ़ती है।
- क्या फुर्तीली परियोजनाएँ आवश्यकताओं की इंजीनियरिंग करती हैं?
- हाँ, लेकिन अलग तरीके से। फुर्तीली परियोजनाएँ उपयोगकर्ता कहानियों, बैकलॉग शोधन और लगातार प्रतिक्रिया के माध्यम से लगातार आवश्यकताओं को जानती हैं, उनका विश्लेषण करती हैं और उन्हें मान्य करती हैं, बजाय इसके कि पहले से एक बड़ा विनिर्देश दस्तावेज़ तैयार किया जाए।