एसडीएलसी में आवश्यकता विश्लेषण और सभा क्या है?

what is requirement analysis

यह ट्यूटोरियल बताता है कि एसडीएलसी में आवश्यकता विश्लेषण, आवश्यकता विश्लेषण कदम, उदाहरण और आवश्यकता की प्राप्ति के लक्ष्य क्या हैं:

सॉफ्टवेयर विकास एक विनम्र कार्य है जो एक कार्यशील सॉफ्टवेयर उत्पाद बनाता है।

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

आप क्या सीखेंगे:

• आवश्यकता विश्लेषण क्या है?
  • आवश्यकता विश्लेषण चरणों / चरणों
    • (1) आवश्यकता सभा
    • # 2) एकत्रित आवश्यकताओं का विश्लेषण
    • # 3) विश्लेषित आवश्यकताओं का दस्तावेजीकरण
  • सॉफ्टवेयर आवश्यकताओं के लिए व्यावसायिक आवश्यकताओं को परिवर्तित करना
  • गैर-कार्यात्मक आवश्यकताओं को समझना
  • व्यावसायिक आवश्यकताओं और सॉफ़्टवेयर आवश्यकताओं के बीच अंतर
• निष्कर्ष
  • अनुशंसित पाठ

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

एक उदाहरण की मदद से आवश्यकता विश्लेषण को समझते हैं।

ग्राहक / अंतिम-उपयोगकर्ता अपेक्षा:

ग्राहक / अंतिम-उपयोगकर्ता प्राप्त:

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

हालांकि, जैसा कि आप देख सकते हैं, यह गलत उत्पाद वितरण के लिए कोई भी कारण हो सकता है, प्राथमिक कारण की आवश्यकता होती है। इसलिए, यदि सही आवश्यकता समझ, कैप्चरिंग, कार्यान्वयन और परीक्षण किया गया था, तो इससे ग्राहक / अंतिम-उपयोगकर्ता को गलत और अपूर्ण उत्पाद वितरण को कम करने में मदद मिली होगी।

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

आवश्यकता विश्लेषण चरणों / चरणों

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

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

आवश्यकता विश्लेषण से शुरू होता है:

1. आवश्यक भीड़ जुटना जिसे एलिसिटेशन भी कहा जाता है।
2. इसके बाद होता है विश्लेषण इन आवश्यकताओं को एक संभावित उत्पाद में परिवर्तित करने की शुद्धता और व्यवहार्यता को समझने के लिए एकत्रित आवश्यकताएं।
3. और अंत में, कुछ दस्तावेज़ीकृत आवश्यकताओं को एकत्र किया।

(1) आवश्यकता सभा

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

कई बार यह संभव नहीं होता है कि ग्राहक से व्यावसायिक विश्लेषकों द्वारा आवश्यक रूप से एकत्रित किया जाता है। यह अपेक्षित अंत उत्पाद, उपकरण, पर्यावरण, आदि से संबंधित कई लोगों पर निर्भरता के कारण हो सकता है। इस प्रकार, हमेशा सभी हितधारकों को शामिल करना एक अच्छा विचार है जो प्रभावित हो सकते हैं या अंतिम उत्पाद से प्रभावित हो सकते हैं।

संभावित हितधारक का समूह सॉफ्टवेयर क्वालिटी इंजीनियर (QC और QA दोनों) हो सकता है, कोई भी थर्ड पार्टी वेंडर जो प्रोजेक्ट में सहायता प्रदान कर सकता है, एंड-यूज़र जिनके लिए उत्पाद का इरादा है, सॉफ़्टवेयर प्रोग्रामर, संगठन के भीतर एक अन्य टीम जो प्रदान कर सकती है। उत्पाद विकास के लिए एक मॉड्यूल या सॉफ्टवेयर प्लेटफॉर्म, सॉफ्टवेयर लाइब्रेरी आदि।

उदाहरण: एक संगठन में, वे एक ADAS उत्पाद (एक प्रतिष्ठित OEM के लिए चारों ओर कैमरा प्रणाली) विकसित करते हैं, जिनकी आवश्यकता होती है ऑटोसार स्टैक तथा बूटलोडर बायनेरिज़ जो किसी अन्य आपूर्तिकर्ता से प्राप्त होते हैं।

आवश्यकता के चरण में विभिन्न हितधारकों को शामिल करने से एक-दूसरे पर विभिन्न निर्भरता को समझने में मदद मिलती है और भविष्य में किसी भी संभावित संघर्ष को रोका जा सकता है।

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

यह प्रोटोटाइप निर्माण दो प्रकार के उत्पाद पर निर्भर करता है:

1. एक समान उत्पाद जो ग्राहकों का इरादा था, संगठन के भीतर मौजूद है।
2. नया उत्पाद विकसित किया जाना है।

(मैं) पहले मामले में, ग्राहक को यह दिखाना आसान है कि अंत उत्पाद कैसा दिखेगा और इसे कैसे विकसित किया जाएगा। मोटर वाहन ADAS में, ग्राहकों को एक और उत्पाद दिखाना संभव है जो पहले से ही बाजार में है और संगठन के भीतर विकसित किया गया था।

उदाहरण के लिए, एक OEM (जीएम, वोक्सवैगन, बीएमडब्ल्यू, आदि) के लिए एक चारों ओर देखने वाला कैमरा सिस्टम विकसित किया गया है और इसे दूसरे ओईएम को दिखाया जा सकता है।

कृपया ध्यान दें यह ग्राहक को उत्पाद / प्रोटो उत्पाद दिखाना बुद्धिमानी नहीं है जो कि विकास के अधीन है क्योंकि यह किसी अन्य ग्राहक के साथ हस्ताक्षरित गैर-प्रकटीकरण समझौते का उल्लंघन कर सकता है जिसके लिए वह उत्पाद विकसित किया जा रहा है। यह एक अनावश्यक कानूनी झंझट में भी पड़ सकता है।

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

इससे ग्राहक को यह समझने में मदद मिलेगी कि अंतिम उत्पाद कैसे दिखेगा और उनकी आवश्यकताओं को अधिक स्पष्ट रूप से प्रदान करेगा।

(ii) दूसरा मामला साधारण कोडिंग और असेंबली करके एक बेसिक वर्किंग मॉडल बनाकर प्राप्त किया जा सकता है (ज्यादातर फीचर्स यहां सॉफ्टवेयर प्रोग्राम में हार्डकोड किए गए हैं), या एक फ्लो चार्ट या डायग्राम बनाकर ग्राहक को समझा सकते हैं कि प्रोडक्ट कैसा दिखेगा।

किसी भी मामले में, यह आवश्यकता को इकट्ठा करने की प्रक्रिया के लिए एक राहत होगी क्योंकि ग्राहक अब जानता है कि उसे क्या चाहिए।

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

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

आवश्यकता को इकट्ठा करने का उदाहरण: ADAS सराउंड-व्यू कैमरा सिस्टम में, एक संभावित उपयोगकर्ता कहानी हो सकती है: 'एक उपयोगकर्ता के रूप में, मुझे यह देखने में सक्षम होना चाहिए कि मेरी कार के रियरव्यू में क्या है'।

कई हो सकते हैं 'क्यों,' प्रत्येक उपयोगकर्ता कहानी पर पूछे जाने वाले प्रश्न, जो आवश्यकता पर अधिक विस्तृत जानकारी प्रदान करने में ग्राहक की मदद करेंगे।

उपर्युक्त उपयोगकर्ता कहानी में, यदि कोई ग्राहक कहता है, 'एक उपयोगकर्ता के रूप में, मुझे यह देखना चाहिए कि मेरी कार के रियरव्यू में क्या है?' 'क्यों 'दे सकता है' एक उपयोगकर्ता के रूप में, मुझे यह देखने में सक्षम होना चाहिए कि मेरी कार के रियरव्यू में क्या है, ताकि मैं अपनी कार को सुरक्षित तरीके से पार्क कर सकूं ”।

सवाल पूछ रहा हूं 'क्यों' ग्राहक द्वारा दिए गए विनम्र प्राकृतिक भाषा बयानों से उद्देश्य और परमाणु आवश्यकताओं को बनाने में भी मदद करता है। इसे बाद में कोड में आसानी से लागू किया जा सकता है।

कैसे यूनिक्स में 2 फ़ाइलों की तुलना करने के लिए

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

उदाहरण:

# 2) एकत्रित आवश्यकताओं का विश्लेषण

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

यह कदम निम्नलिखित मुख्य कारणों के कारण आवश्यकता विश्लेषण प्रक्रिया में महत्वपूर्ण है:

(मैं) ग्राहक कुछ आवश्यकताएं प्रदान कर सकता है जो विभिन्न निर्भरता के कारण लागू करना असंभव हो सकता है।

उदाहरण: ग्राहकोंरियरव्यू कैमरा फ़ीचर के साथ कैमरा सिस्टम को घेरने के लिए कह सकता है जो मदद करेगा पार्किंग कार। ग्राहक भी मांग सकता है ट्रेलर अड़चन सुविधा जो काम करने के लिए रियर कैमरा का उपयोग करती है।

यदि ग्राहक एक आवश्यकता बताता है कि रियरव्यू कैमरा के लिए पार्किंग सहायता अपवाद के बिना हर समय काम करना चाहिए, फिर ट्रेलर सुविधा कभी काम नहीं करेगी और इसके विपरीत।

(ii) एक व्यावसायिक विश्लेषक ने आवश्यकता से समझा हो सकता है ग्राहक कैसे एक से अलग प्रोग्रामर व्याख्या की होगी।

चूंकि प्रोग्रामर तकनीकी विशेषज्ञों के रूप में सोचते हैं, इसलिए यह हमेशा संभव है कि ग्राहक की आवश्यकताओं को गलत तरीके से कार्यात्मक विनिर्देशों में परिवर्तित किया जाए जो बाद में वास्तुकला और डिजाइन दस्तावेजों के लिए गलत तरीके से बनाया जाएगा और बाद में कोड के लिए। प्रभाव घातीय है और इसलिए जाँच की जानी चाहिए।

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

# 3) विश्लेषित आवश्यकताओं का दस्तावेजीकरण

एक बार आवश्यकताओं के विश्लेषण के बाद आवश्यकता प्रलेखन शुरू हो जाती है। आवश्यकताओं के विश्लेषण से विभिन्न प्रकार की आवश्यकताएँ निकलती हैं।

इनमें से कुछ हैं:

(मैं) ग्राहक की आवश्यकता के विनिर्देश।

(ii) सॉफ्टवेयर आर्किटेक्चर की आवश्यकता।

उदाहरण:

(iii) सॉफ्टवेयर डिजाइन की आवश्यकता।

उदाहरण:

(iv) कार्यात्मक आवश्यकता विनिर्देश (सीधे ग्राहक विनिर्देशों से प्राप्त)

उदाहरण: 'जब उपयोगकर्ता इन्फोटेनमेंट एचएमआई पर ब्लूटूथ आइकन पर टैप करता है, तो ब्लूटूथ स्क्रीन प्रदर्शित की जानी चाहिए'

(v) गैर-कार्यात्मक आवश्यकता विनिर्देश (अर्थात प्रदर्शन, तनाव, भार, आदि)।

उदाहरण: 'सिस्टम प्रदर्शन में गिरावट के बिना इंफोटेनमेंट सिस्टम के साथ 15 ब्लूटूथ डिवाइस को पेयर करना संभव होना चाहिए'।

(हम) उपयोगकर्ता इंटरफ़ेस आवश्यकताओं।

उदाहरण: 'ट्यूनर एफएम स्क्रीन पर, विभिन्न स्टेशनों का चयन करने के लिए एक बटन प्रदान किया जाना चाहिए'

उपरोक्त आवश्यकताएं आईबीएम दरवाजे, एचपी क्यूसी जैसे आवश्यकता प्रबंधन उपकरणों में दर्ज और प्रलेखित हैं। कभी-कभी संगठनों के पास लागत को कम करने के लिए उनके कस्टम-मेड आवश्यकता प्रबंधन उपकरण होते हैं।

अब हम परिवर्तित करने की प्रक्रिया को देखते हैं व्यापार की आवश्यकताओं सेवा मेरे सॉफ़्टवेयर आवश्यकताएं (कार्यात्मक और गैर-कार्यात्मक)।

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

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

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

ऐसा करने के लिए, निम्नलिखित चरणों का पालन किया जा सकता है:

1. उपयोगकर्ता कहानियों को विस्तृत करने के लिए उच्च-स्तरीय व्यावसायिक आवश्यकताओं को तोड़ें।
2. गतिविधियों के प्रवाह को परिभाषित करने के लिए एक फ़्लोचार्ट प्राप्त करना।
3. वह स्थिति प्रदान करना जो व्युत्पन्न उपयोगकर्ता कहानियों को सही ठहराता है।
4. वायरफ्रेम आरेख वस्तुओं के वर्कफ़्लो को समझाने के लिए।
5. गैर-कार्यात्मक आवश्यकताओं को परिभाषित करना व्यावसायिक आवश्यकताओं से बाहर है।

आइए एक उदाहरण ऑटोमोटिव इंफोटेनमेंट सिस्टम का उपयोग करके शुरू करते हैं।

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

इसलिए, उपरोक्त सूचीबद्ध कदमों को इस प्रकार लागू किया जा सकता है:

(1) विस्तृत उपयोगकर्ता कहानियों के लिए उच्च-स्तरीय व्यावसायिक आवश्यकताओं को तोड़ना।

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

आइए इस उपयोगकर्ता कहानी के लिए संभावित प्रश्न पूछकर शुरुआत करें।

क्या एक .jar फ़ाइल को खोलता है

1. उपयोगकर्ता कौन हैं?
2. मैं नेविगेशन, जहाज पर (एसडी कार्ड से) या स्मार्टफ़ोन से कैसे एक्सेस कर सकता हूं?
3. मैं किस प्रकार की गंतव्य प्रविष्टियाँ दर्ज कर सकता हूँ?
4. क्या कार पार्किंग में होने पर भी मुझे गंतव्य में प्रवेश करने की अनुमति दी जानी चाहिए?

ये उच्च स्तरीय उपयोगकर्ता कहानियों से ली गई अधिक विस्तृत स्तर की उपयोगकर्ता कहानियां हैं और हमारी व्यावसायिक आवश्यकता में अधिक जानकारी प्राप्त करने में हमारी मदद करेंगी।

इस बिंदु पर, हम उपयोगकर्ता की उप-कहानियों में से एक को ले सकते हैं और पूछताछ शुरू कर सकते हैं। हमें लेते हैं (नहीं। 3):

1. क्या मैं गंतव्य प्रविष्टियों जैसे कि जियो कोऑर्डिनेट्स, पोस्टल एड्रेस, स्पीच रिकग्निशन के माध्यम से प्रवेश कर सकता हूं?
2. क्या मुझे जियो-निर्देशांक दर्ज करने के लिए जीपीएस की आवश्यकता है?
3. क्या मैं पतों के इतिहास से खोजकर वर्तमान गंतव्य पते में प्रवेश कर सकता हूं?

# 2) गतिविधियों के प्रवाह को परिभाषित करने के लिए एक फ्लोचार्ट का वितरण।

अब हम देख सकते हैं कि व्यापार की आवश्यकता बहुत विस्तृत उपयोग के मामलों में टूट गई है, जो नीचे के रूप में फ़्लोचार्ट में चिह्नित किए जा सकते हैं:

# 3) ऐसी स्थितियाँ प्रदान करना जो व्युत्पन्न उपयोगकर्ता कहानियों को सही ठहराती हैं।

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

• गंतव्य प्रविष्टि प्रदर्शित करने के लिए स्क्रीन लोडिंग समय 1 सेकंड होना चाहिए।
• गंतव्य प्रविष्टि कीबोर्ड में अल्फ़ान्यूमेरिक वर्ण और विशेष प्रतीक होने चाहिए।
• नेविगेशन गंतव्य प्रविष्टि स्क्रीन पर GPS सक्षम / अक्षम टॉगल बटन मौजूद होना चाहिए।

उपरोक्त जानकारी उपयोगकर्ता कहानियों को संतुष्ट करती है और सुविधाओं के रूप में कार्यान्वित होने के दौरान आवश्यकता के साथ किसी भी भ्रम से बचने के लिए विवेकपूर्ण और औसतन परीक्षण की आवश्यकता के लिए संभव बनाती है।

# 4) वायरफ्रेम आरेख वस्तुओं के वर्कफ़्लो को समझाने के लिए।

उपरोक्त उपयोग के मामले से, हम एक वायरफ्रेम आरेख प्राप्त करेंगे जो उपयोगकर्ता इंटरफ़ेस को स्पष्ट करेगा।

# 5) गैर-कार्यात्मक आवश्यकताओं को परिभाषित करना व्यावसायिक आवश्यकताओं से बाहर है।

यह आवश्यक है कि विस्तृत सॉफ़्टवेयर आवश्यकताओं को उच्च-स्तरीय व्यावसायिक आवश्यकताओं से प्राप्त किया जाता है, लेकिन कई बार केवल कार्यात्मक आवश्यकताओं की पहचान की जाती है, जो कहती है कि सिस्टम किसी विशेष उपयोगकर्ता इनपुट / कार्रवाई के लिए कैसे व्यवहार करेगा।

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

उदाहरण:

a) हम उपरोक्त ऑटोमोटिव इंफोटेनमेंट सिस्टम का उदाहरण लेंगे।

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

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

b) एक अन्य मामला स्ट्रेस परिदृश्य है।

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

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

गैर-कार्यात्मक आवश्यकताओं को समझना

नीचे दी गई तालिका गैर-कार्यात्मक आवश्यकताओं की व्याख्या करती है:

गैर-कार्यात्मक आवश्यकताएं, कार्यात्मक आवश्यकताओं के विपरीत, कार्यान्वित होने के लिए एक परियोजना का पूरा जीवन चक्र लेती हैं, क्योंकि वे संबंधित Agile Sprints या विभिन्न पुनरावृत्तियों में वृद्धिशील रूप से कार्यान्वित किए जाते हैं।

तो, यह है कि हम व्यावसायिक आवश्यकताओं से सॉफ़्टवेयर आवश्यकताएँ कैसे प्राप्त करते हैं।

व्यावसायिक आवश्यकताओं और सॉफ़्टवेयर आवश्यकताओं के बीच अंतर

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

आइए हम दो आवश्यकता प्रकारों के बीच विस्तृत अंतर पर ध्यान दें।

निष्कर्ष

आवश्यकता विश्लेषण किसी भी SDLC मॉडल की रीढ़ है।

आवश्यकता विश्लेषण के दौरान याद किया गया एक मुद्दा और यूनिट परीक्षण में पकड़ा गया एक संगठन के लिए हजारों डॉलर का खर्च कर सकता है और यह लागत लाखों डॉलर हो सकती है अगर यह बाजार से कॉलबैक के रूप में आता है (2017 में, यूएसए ने एयरबैग निर्माता, तकाता को चार्ज किया एयरबैग में विस्फोट के कारण $ 1 बिलियन का जुर्माना)।

संगठन सॉफ्टवेयर विकास और गुणवत्ता पर ध्यान केंद्रित करने के बजाय मूल कारण विश्लेषण, जैसे 5 क्यों दस्तावेज, दोष वृक्ष विश्लेषण, 8D दस्तावेज़, आदि तैयार करने के लिए क्षति नियंत्रण कार्य करता है।

सबसे बुरी स्थिति में, संगठन को ग्राहक द्वारा दायर कानूनी मुकदमों में घसीटा जाएगा यदि प्रभावित सुविधा सुरक्षा / सुरक्षा से संबंधित है जैसे सुरक्षा पहुंच, एयरबैग, एबीएस (एंटी-लॉक ब्रेकिंग सिस्टम), आदि।

अनुशंसित पाठ

• एसडीएलसी (सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल) चरण, तरीके, प्रक्रिया और मॉडल
• कार्यात्मक आवश्यकताओं और गैर कार्यात्मक आवश्यकताओं की विशेषताएं
• सॉफ्टवेयर आवश्यकताएँ विशिष्टता (SRS) का परीक्षण कैसे करें?
• आवश्यकताएँ प्रबंधन में 5 घातक गलतियाँ और उन्हें कैसे काबू करें
• आवश्यकताओं के बिना किसी एप्लिकेशन का परीक्षण कैसे करें?
• SSDLC के लिए उपाय (सुरक्षित सॉफ्टवेयर विकास जीवन चक्र)
• सर्पिल मॉडल - एसडीएलसी सर्पिल मॉडल क्या है?
• एसडीएलसी झरना मॉडल क्या है?