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



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

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

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

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

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

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

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

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

ताकत

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

कमजोरियां

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

यह भी देखें

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

बाहरी संबंध

 * Peer-reviewed Encyclopedia Entry on Requirements Engineering and Analysis
 * Defense Acquisition University Stakeholder Requirements Definition Process---
 * MIL-HDBK 520 Systems Requirements Document Guidance

Wymaganie (inżynieria)