आवश्यकताओं के विश्लेषण

For broader coverage of this topic, see आवश्यकताएं इंजीनियरिंग.

आवश्यकताओं के विश्लेषण पर एक प्रणाली अभियांत्रिकी परिप्रेक्ष्य।

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

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

अवलोकन

वैचारिक रूप से, आवश्यकताओं के विश्लेषण में तीन प्रकार की गतिविधियाँ सम्मिलित हैं:

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

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

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

आवश्यकता विश्लेषण विषय

हितधारक पहचान

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

1990 के दशक में एक प्रमुख नया जोर हितधारकों की पहचान पर केंद्रित था। यह तेजी से मान्यता प्राप्त है कि हितधारक विश्लेषक को नियुक्त करने वाले संगठन तक ही सीमित नहीं हैं। अन्य हितधारकों में सम्मिलित होंगे:

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

संयुक्त आवश्यकताएं विकास (जेआरडी) सत्र

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

जेआरडी सत्र संयुक्त अनुप्रयोग डिजाइन सत्र के समान हैं। पूर्व में, सत्र आवश्यकताओं को पूरा करते हैं जो डिजाइन को निर्देशित करते हैं, जबकि बाद वाले विशिष्ट डिजाइन सुविधाओं को विशिष्ट आवश्यकताओं की संतुष्टि में लागू करने के लिए प्रेरित करते हैं।

अनुबंध-शैली की आवश्यकता सूची

आलेख ीकरण आवश्यकताओं का एक पारंपरिक विधियाँ अनुबंध शैली आवश्यकता सूची रहा है। एक जटिल प्रणाली में ऐसी आवश्यकताओं की सूची सैकड़ों पृष्ठों तक लंबी हो सकती है।

एक उपयुक्त रूपक खरीदारी की एक बहुत लंबी सूची होगी। ऐसी सूचियाँ आधुनिक विश्लेषण में बहुत अधिक अनुकूल हैं; क्योंकि वे अपने लक्ष्यों को प्राप्त करने में शानदार रूप से असफल सिद्ध हुए हैं; लेकिन वे आज भी देखे जाते हैं।

ताकत

• आवश्यकताओं की एक चेकलिस्ट प्रदान करता है।
• परियोजना प्रायोजक(रों) और डेवलपर्स के बीच एक अनुबंध प्रदान करें।
• एक बड़ी प्रणाली के लिए एक उच्च स्तरीय विवरण प्रदान कर सकता है जिससे निचले स्तर की आवश्यकताओं को प्राप्त किया जा सकता है।

कमजोरियां

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

आवश्यकता सूचियों का विकल्प

आवश्यकता सूचियों के विकल्प के रूप में, फुर्तीली सॉफ़्टवेयर डेवलपमेंट रोज़मर्रा की भाषा में आवश्यकताओं का सुझाव देने के लिए उपयोगकर्ता कहानियों का उपयोग करती है।

मापने योग्य लक्ष्य

Main article: Goal modeling

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

प्रोटोटाइप

Main article: Software prototyping

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

स्थितियों का प्रयोग करें

Main article: Use case

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

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

सॉफ्टवेयर आवश्यकता विनिर्देश

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

आवश्यकताओं के प्रकार

आवश्यकताएँ कई तरह से वर्गीकरण हैं। तकनीकी प्रबंधन से संबंधित आवश्यकताओं के सामान्य वर्गीकरण निम्नलिखित हैं:

व्यापार की आवश्यकताओं

विस्तृत कार्यक्षमता के संदर्भ के बिना व्यापार स्तर के लक्ष्यों का विवरण। ये आम तौर पर उच्च स्तरीय (सॉफ़्टवेयर और/या हार्डवेयर) क्षमताएं होती हैं जिनकी व्यावसायिक परिणाम प्राप्त करने के लिए आवश्यकता होती है।

ग्राहक की आवश्यकताएं

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

• मिशन प्रोफ़ाइल या परिदृश्य: प्रणाली अपने मिशन के उद्देश्य को कैसे पूरा करेगा?
• प्रदर्शन और संबंधित पैरामीटर: मिशन को पूरा करने के लिए महत्वपूर्ण प्रणाली पैरामीटर क्या हैं?

* उपयोगिता वातावरण: विभिन्न प्रणाली घटकों का उपयोग कैसे किया जाता है?

• प्रभावकारिता आवश्यकताएँ: प्रणाली अपने मिशन को पूरा करने में कितना प्रभावी या कुशल होना चाहिए?
• परिचालन जीवन चक्र: उपयोगकर्ता द्वारा प्रणाली कब तक उपयोग में रहेगा?
• पर्यावरण: प्रणाली के प्रभावी ढंग से संचालन के लिए किस वातावरण की अपेक्षा की जाएगी?

आर्किटेक्चरल आवश्यकताएं: आर्किटेक्चरल आवश्यकताएं बताती हैं कि प्रणाली के आवश्यक प्रणाली आर्किटेक्चर की पहचान करके क्या किया जाना चाहिए। संरचनात्मक आवश्यकताएं: संरचनात्मक आवश्यकताएं बताती हैं कि प्रणाली की आवश्यक संरचना की पहचान करके क्या किया जाना है। व्यवहार संबंधी आवश्यकताएं: व्यवहार संबंधी आवश्यकताएं बताती हैं कि प्रणाली के आवश्यक व्यवहार की पहचान करके क्या किया जाना है। कार्यात्मक आवश्यकताएं: कार्यात्मक आवश्यकताएं बताती हैं कि आवश्यक कार्य, क्रिया या गतिविधि की पहचान करके क्या किया जाना चाहिए जिसे पूरा किया जाना चाहिए। कार्यात्मक आवश्यकताओं के विश्लेषण का उपयोग कार्यात्मक विश्लेषण के लिए उच्च स्तरीय कार्यों के रूप में किया जाएगा।;गैर-कार्यात्मक आवश्यकताएं: गैर-कार्यात्मक आवश्यकताएं ऐसी आवश्यकताएं हैं जो मानदंड निर्दिष्ट करती हैं जिनका उपयोग विशिष्ट व्यवहारों के बजाय प्रणाली के संचालन का न्याय करने के लिए किया जा सकता है।

प्रदर्शन आवश्यकताएँ

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

प्रसिद्ध आवश्यकता वर्गीकरण मॉडल में हेवलेट पैकर्ड में विकसित FURPS और FURPS+ सम्मिलित हैं।

आवश्यकता विश्लेषण मुद्दे

हितधारक मुद्दे

स्टीव मैककोनेल, अपनी पुस्तक रैपिड डेवलपमेंट में, ऐसे कई तरीकों का विवरण देते हैं, जिनसे उपयोगकर्ता आवश्यकताओं को एकत्रित करने से रोक सकते हैं:

• उपयोगकर्ता यह नहीं समझते हैं कि वे क्या चाहते हैं या उपयोगकर्ताओं को उनकी आवश्यकताओं के बारे में स्पष्ट जानकारी नहीं है
• उपयोगकर्ता लिखित आवश्यकताओं के एक सेट के लिए प्रतिबद्ध नहीं होंगे
• उपयोगकर्ता लागत और शेड्यूल तय होने के बाद नई आवश्यकताओं पर जोर देते हैं
• उपयोगकर्ताओं के साथ संचार धीमा है
• उपयोगकर्ता अधिकांशतः समीक्षाओं में भाग नहीं लेते या ऐसा करने में असमर्थ होते हैं
• उपयोगकर्ता तकनीकी रूप से अपरिष्कृत हैं
• उपयोगकर्ता विकास प्रक्रिया को नहीं समझते हैं
• उपयोक्ता वर्तमान तकनीक के बारे में नहीं जानते

इससे ऐसी स्थिति हो सकती है जहां प्रणाली या उत्पाद विकास शुरू होने पर भी उपयोगकर्ता की आवश्यकताएं बदलती रहती हैं।

इंजीनियर/डेवलपर मुद्दे

आवश्यकताओं के विश्लेषण के समय इंजीनियरों और डेवलपर्स के कारण होने वाली संभावित समस्याएं हैं:

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

प्रयास किए गए समाधान

संचार समस्याओं के समाधान का एक प्रयास व्यवसाय या प्रणाली विश्लेषण में विशेषज्ञों को नियुक्त करना रहा है।

1990 के दशक में शुरू की गई तकनीक जैसे सॉफ्टवेयर प्रोटोटाइपिंग, एकीकृत मॉडलिंग भाषा (UML), केस का उपयोग करें, और फुर्तीली सॉफ्टवेयर डेवलपमेंट भी पिछले तरीकों के साथ आने वाली समस्याओं के समाधान के रूप में हैं।

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

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

यह भी देखें

• व्यावसायिक विश्लेषण
• व्यापार विश्लेषण ज्ञान का निकाय (बाबोक)
• व्यावसायिक प्रक्रिया रीइंजीनियरिंग
• रचनात्मक संक्षिप्त
• मॉडलिंग की दिनांक
• संक्षेप डिज़ाइन
• कार्यकारी आवश्यकताएं
• सूचान प्रौद्योगिकी
• मॉडल संचालित इंजीनियरिंग
• मॉडल परिवर्तन भाषा
• आकलन की आवश्यकता है
• गैर-कार्यात्मक आवश्यकताएं
• प्रक्रिया संरचना
• प्रक्रिया मॉडलिंग
• उत्पाद फिट विश्लेषण
• आवश्यकता निकालना
• आवश्यकताएँ इंजीनियरिंग विशेषज्ञ समूह
• आवश्यकता प्रबंधन
• आवश्यकताएँ पता लगाने की क्षमता
• खोज आधारित सॉफ्टवेयर इंजीनियरिंग
• सॉफ्टवेयर प्रोटोटाइप
• सॉफ़्टवेयर आवश्यकताएं
• सॉफ्टवेयर आवश्यकता विशिष्टता
• सिस्टम विश्लेषण
• सिस्टम आवश्यकताएं
• सिस्टम आवश्यकताएँ विनिर्देश
• उपयोगकर्ता-केंद्रित डिजाइन

ग्रन्थसूची

• Brian Berenbach; Daniel Paulish; Juergen Katzmeier; Arnold Rudorfer (2009). Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Professional. ISBN 978-0-07-160547-2.
• Hay, David C. (2003). Requirements Analysis: From Business Views to Architecture (1st ed.). Upper Saddle River, NJ: Prentice Hall. ISBN 0-13-028228-6.
• Laplante, Phil (2009). Requirements Engineering for Software and Systems (1st ed.). Redmond, WA: CRC Press. ISBN 978-1-4200-6467-4.
• McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules (1st ed.). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.
• Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap (PDF). ICSE'00. Proceedings of the conference on the future of Software engineering. pp. 35–46. CiteSeerX 10.1.1.131.3116. doi:10.1145/336512.336523. ISBN 1-58113-253-0.
• Andrew Stellman & Jennifer Greene (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.
• Karl Wiegers & Joy Beatty (2013). Software Requirements (3rd ed.). Redmond, WA: Microsoft Press. ISBN 978-0-7356-7966-5.

बाहरी संबंध

• Peer-reviewed Encyclopedia Entry on Requirements Engineering and Analysis
• Defense Acquisition University Stakeholder Requirements Definition Process---Stakeholder Requirements Definition Process at the Wayback Machine (archived December 23, 2015)
• MIL-HDBK 520 Systems Requirements Document Guidance