कार्यात्मक आवश्यकताओं और गैर कार्यात्मक आवश्यकताओं की विशेषताएं

features functional requirements

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

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

सिस्टम में कार्यात्मक आवश्यकता कार्यान्वयन की योजना सिस्टम डिज़ाइन चरण में बनाई गई है, जबकि गैर-कार्यात्मक आवश्यकताओं के मामले में, यह सिस्टम आर्किटेक्चर दस्तावेज़ में योजनाबद्ध है। कार्यात्मक आवश्यकता गैर-कार्यात्मक आवश्यकताओं को उत्पन्न करने का समर्थन करती है।

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

• कार्यात्मक आवश्यकताओं और गैर कार्यात्मक आवश्यकताओं
  • कार्यकारी आवश्यकताएं
    • कार्यात्मक आवश्यकताओं के प्रकार
  • व्यावसायिक आवश्यकताएं बनाम कार्यात्मक आवश्यकताएं
  • गैर कार्यात्मक आवश्यकता
    • गैर-कार्यात्मक आवश्यकताओं के प्रकार
  • कार्यात्मक आवश्यकताओं से गैर-कार्यात्मक आवश्यकताएं प्राप्त करना
• कार्यात्मक बनाम गैर कार्यात्मक आवश्यकताएं
• निष्कर्ष
  • अनुशंसित पाठ

कार्यात्मक आवश्यकताओं और गैर कार्यात्मक आवश्यकताओं

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

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

उदाहरण: एक मोटर वाहन ADAS परियोजना में, एक चारों ओर देखने की प्रणाली कार्यात्मक आवश्यकता 'रियर कैमरा एक खतरे या वस्तु का पता लगाना चाहिए'। गैर-कार्यात्मक आवश्यकताएं यहां हो सकती हैं 'कैमरा सेंसर द्वारा किसी खतरे का पता चलने पर उपयोगकर्ता को चेतावनी कितनी जल्दी दिखाई जानी चाहिए'।

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

कैसे एडोब फ़्लैश प्लेयर के साथ swf फ़ाइलों को खोलने के लिए

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

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

कार्यात्मक आवश्यकताओं में निम्नलिखित घटक शामिल हो सकते हैं जिन्हें कार्यात्मक परीक्षण के भाग के रूप में मापा जा सकता है:

# 1) अंतर: आवश्यकता का वर्णन है कि क्या एक सॉफ्टवेयर सिस्टम विभिन्न प्रणालियों के बीच अंतर है।

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

इसलिए इंटरऑपरेबिलिटी जांचती है कि दो अलग-अलग उपकरणों के बीच संचार संभव है या नहीं।

एक और उदाहरण जीमेल जैसी ईमेल सेवा प्रणालियों से है। Gmail Yahoo.com या Rediffmail.com जैसे अन्य मेल एक्सचेंज सर्वर से ईमेल आयात करने की अनुमति देता है। ईमेल सर्वरों के बीच अंतर के कारण यह संभव है।

# 2) सुरक्षा: कार्यात्मक आवश्यकता सॉफ्टवेयर आवश्यकताओं के सुरक्षा पहलू का वर्णन करती है।

उदाहरण: ADAS सराउंड-व्यू कैमरा-आधारित प्रणाली में साइबर सुरक्षा आधारित सेवाएं जो नियंत्रक क्षेत्र नेटवर्क (CAN) का उपयोग करती हैं जो सिस्टम को सुरक्षा खतरे से बचाती हैं।

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

# 3) सटीकता: सटीकता परिभाषित करती है कि सिस्टम में दर्ज किया गया डेटा सही तरीके से सिस्टम द्वारा गणना और उपयोग किया जाता है और आउटपुट सही है।

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

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

# 4) अनुपालन: अनुपालन कार्यात्मक आवश्यकताएं मानती हैं कि विकसित प्रणाली औद्योगिक मानकों के अनुरूप है।

उदाहरण: चाहे ब्लूटूथ प्रोफाइल फंक्शनालिटीज (A2DP के माध्यम से ऑडियो स्ट्रीमिंग, HFP के माध्यम से फोन कॉल) ब्लूटूथ SIG रिलीज प्रोफाइल संस्करणों के अनुरूप हो।

एक और उदाहरण हो सकता है कि Apple कार कार इंफोटेनमेंट सिस्टम में चलाए। इंफोटेनमेंट में ऐप से एक सर्टिफिकेट मिलता है सेब यदि Apple वेबसाइट में उल्लिखित सभी पूर्व शर्त तृतीय-पक्ष कार प्ले डिवाइस (इस मामले में सूचना) से पूरी होती हैं।

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

आवश्यकता के रूप का उदाहरण:

हमने पहले ही देखा है कि कुछ उदाहरणों के साथ कार्यात्मक आवश्यकता क्या है। आइए अब देखते हैं कि आईबीएम दरवाजे जैसे आवश्यकता प्रबंधन उपकरण में एकीकृत होने पर एक कार्यात्मक आवश्यकता क्या दिखती है। आवश्यकता प्रबंधन उपकरण में एक कार्यात्मक आवश्यकता का दस्तावेजीकरण करते समय कई विशेषताओं को ध्यान में रखा जाना चाहिए।

नीचे कुछ विशेषताओं को ध्यान में रखा जाना चाहिए:

1. वस्तु प्रकार: यह विशेषता बताती है कि आवश्यकता दस्तावेज़ का कौन सा भाग इस विशेषता का हिस्सा है। वे हेडिंग, स्पष्टीकरण, आवश्यकता, आदि हो सकते हैं। अधिकतर 'आवश्यकता' अनुभाग को कार्यान्वयन और परीक्षण के लिए माना जाता है, जबकि शीर्ष और स्पष्टीकरण अनुभागों को बेहतर समझ के लिए आवश्यकताओं के समर्थन विवरण के रूप में उपयोग किया जाता है।
2. जिम्मेदार व्यक्ति: एक लेखक जिसने आवश्यकता प्रबंधन उपकरण में आवश्यकता का दस्तावेजीकरण किया है।
3. प्रोजेक्ट / सिस्टम का नाम: वह परियोजना जिसके लिए आवश्यकता लागू है, उदाहरण के लिए, 'XYZ OEM के लिए इंफोटेनमेंट सिस्टम (मूल उपकरण निर्माता) एक ऑटोमोटिव कंपनी या एबीसी बैंकिंग लिमिटेड कंपनी के लिए वेब एप्लिकेशन'।
4. आवश्यकता संस्करण संख्या: यह फ़ील्ड / विशेषता आवश्यकता के संस्करण संख्या को सूचित करती है, यदि आवश्यकता ग्राहक के अपडेट या सिस्टम डिज़ाइन में परिवर्तन के कारण कई संशोधनों से गुजरती है।
5. आवश्यकता आईडी: इस विशेषता में अद्वितीय आवश्यकता आईडी का उल्लेख है। आवश्यकता आईडी का उपयोग डेटाबेस में आवश्यकताओं को आसानी से ट्रैक करने और कोड में आवश्यकताओं को कुशलतापूर्वक मैप करने में किया जाता है। इसका उपयोग बग ट्रैकिंग टूल में दोषों को लॉग करते समय आवश्यकताओं के संदर्भ प्रदान करने के लिए भी किया जा सकता है।
6. आवश्यकता विवरण: यह विशेषता सबसे महत्वपूर्ण विशेषताओं में से एक है जो आवश्यकता को समझाती है। इस विशेषता को पढ़कर, एक इंजीनियर आवश्यकता को समझने में सक्षम होगा।
7. आवश्यकता स्थिति: आवश्यकता स्थिति विशेषता आवश्यकता प्रबंधन उपकरण में एक आवश्यकता की स्थिति के बारे में कहती है यानी कि क्या यह स्वीकार किया जाता है, ऑन-होल्ड, अस्वीकार या परियोजना को हटा दिया गया है।
8. टिप्पणियाँ: यह विशेषता जिम्मेदार व्यक्ति या आवश्यकता प्रबंधक को आवश्यकता के बारे में किसी भी टिप्पणी का दस्तावेजीकरण करने का विकल्प प्रदान करती है। उदाहरण: एक कार्यात्मक आवश्यकता के लिए एक संभावित टिप्पणी 'आवश्यकता को लागू करने के लिए एक तृतीय-पक्ष सॉफ़्टवेयर पैकेज पर निर्भरता' हो सकती है।

दरवाजे से एक स्नैपशॉट

व्यापार की आवश्यकताओं से कार्यात्मक आवश्यकताओं को प्राप्त करना

यह पहले से ही अनुभाग के हिस्से के रूप में कवर किया गया है ” व्यावसायिक आवश्यकताओं से कार्यात्मक आवश्यकताओं को प्राप्त करना ' के नीचे आवश्यकता विश्लेषण लेख।

व्यावसायिक आवश्यकताएं बनाम कार्यात्मक आवश्यकताएं

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

गैर कार्यात्मक आवश्यकता

गैर-कार्यात्मक आवश्यकता 'क्या सिस्टम होना चाहिए' के बजाय 'एक सिस्टम क्या करना चाहिए' (कार्यात्मक आवश्यकता) के बारे में कहता है। वे ज्यादातर ग्राहक और अन्य हितधारकों से इनपुट के आधार पर कार्यात्मक आवश्यकताओं से प्राप्त होते हैं। गैर-कार्यात्मक आवश्यकता कार्यान्वयन विवरण सिस्टम आर्किटेक्चर दस्तावेज़ में दर्ज़ किए गए हैं।

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

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

पोर्टेबिलिटी और स्थिरता जैसी विभिन्न गुणवत्ता विशेषताओं की उपस्थिति के कारण विकिपीडिया गैर-कार्यात्मक आवश्यकता को कभी-कभी ‘यूटिलिटी’ के रूप में कहता है।

गैर-कार्यात्मक आवश्यकताओं के प्रकार

गैर-कार्यात्मक आवश्यकताओं में उपप्रकार (गैर-निकास) शामिल हैं:

# 1) प्रदर्शन:

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

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

कृपया याद रखें कि सिस्टम प्रदर्शन माप लोड माप से अलग है। लोड परीक्षण के दौरान, हम सिस्टम सीपीयू और रैम को लोड करते हैं और सिस्टम थ्रूपुट की जांच करते हैं। प्रदर्शन के मामले में, हम सामान्य भार / तनाव स्थितियों में सिस्टम थ्रूपुट का परीक्षण करते हैं।

# 2) प्रयोज्यता :

प्रयोज्यता सॉफ्टवेयर प्रणाली के प्रयोज्य का विकास किया जा रहा है।

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

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

# 3) रखरखाव :

एक सॉफ्टवेयर सिस्टम की स्थिरता वह आसानी है जिसके साथ सिस्टम को बनाए रखा जा सकता है। यदि सिस्टम के विकसित होने का औसत समय (एमटीबीएफ) कम या मीन टाइम टू रिपेयर (एमटीटीआर) अधिक है, तो सिस्टम की स्थिरता कम मानी जाती है।

साइक्लोमैटिक जटिलता का उपयोग करके अक्सर कोड स्तर पर स्थिरता को मापा जाता है। साइक्लोमैटिक जटिलता कहती है कि कोड जितना कम जटिल है, सॉफ़्टवेयर को बनाए रखना उतना ही आसान है।

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

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

# 4) विश्वसनीयता :

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

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

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

# 5) पोर्टेबिलिटी:

पोर्टेबिलिटी का मतलब है कि सॉफ्टवेयर सिस्टम की क्षमता एक अलग वातावरण में काम करने की है अगर अंतर्निहित निर्भरता एक समान रहती है।

उदाहरण: ऑटोमोटिव कार निर्माता के लिए विकसित एक इंफोटेनमेंट सिस्टम में सॉफ्टवेयर सिस्टम / कंपोनेंट (अर्थात ब्लूटूथ सर्विस या मल्टी मीडिया सर्विस) को कोड में बहुत कम या कोई बदलाव के साथ किसी अन्य इंफोटेनमेंट सिस्टम में उपयोग करने की अनुमति देनी चाहिए, हालांकि दो इंफोटेनमेंट सिस्टम पूरी तरह से अलग हैं ।

हमें दूसरा लेने दो उदाहरण व्हाट्सएप से। आईओएस, एंड्रॉइड, विंडोज, टैबलेट, लैपटॉप और फोन पर मैसेजिंग सर्विस को इंस्टॉल और इस्तेमाल करना संभव है।

# 6) समर्थन:

एक सॉफ्टवेयर सिस्टम की सेवा एक वास्तविक समय के वातावरण में सॉफ्टवेयर सिस्टम को स्थापित करने के लिए सेवा / तकनीकी विशेषज्ञ की क्षमता है, सिस्टम को मॉनिटर करते हुए चल रहा है, सिस्टम में किसी भी तकनीकी मुद्दों की पहचान करें और समस्या को हल करने के लिए एक समाधान प्रदान करें।

यदि सर्विसिबिलिटी की सुविधा के लिए सिस्टम को विकसित किया जाता है तो सर्विसबिलिटी संभव है।

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

एक और उदाहरण से फिर से लिखना। जब वेब-आधारित मेलिंग सेवा के संस्करण में एक अद्यतन था, तो सिस्टम ने उपयोगकर्ता को मेलिंग सिस्टम के एक नए संस्करण में कुछ महीनों तक बरकरार रखने की अनुमति दी। यह उपयोगकर्ता अनुभव को भी बढ़ाता है।

# 7) अनुकूलन:

एक प्रणाली की अनुकूलनशीलता को एक सॉफ्टवेयर प्रणाली की क्षमता के रूप में परिभाषित किया जाता है जो अपने व्यवहार में किसी भी बदलाव के बिना पर्यावरण में बदलाव के लिए अनुकूलन कर सकती है।

उदाहरण: कार में एंटीलॉक ब्रेकिंग सिस्टम सभी मौसम की स्थिति (गर्म या ठंडा) में मानक के अनुसार काम करना चाहिए। एक और उदाहरण यह एक Android ऑपरेटिंग सिस्टम का हो सकता है। इसका उपयोग विभिन्न प्रकार के उपकरणों में किया जाता है, अर्थात। स्मार्टफोन, टैबलेट कंप्यूटर और इन्फोटेनमेंट सिस्टम और अत्यधिक अनुकूलनीय हैं।

ऊपर सूचीबद्ध 7 गैर-कार्यात्मक आवश्यकताओं के अलावा, हमारे पास कई अन्य हैं जैसे:

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

इन सभी गैर-कार्यात्मक आवश्यकताओं को कवर करना इस लेख के दायरे से बाहर है। हालाँकि, आप इन गैर-कार्यात्मक आवश्यकता प्रकारों के बारे में अधिक पढ़ सकते हैं विकिपीडिया।

अनुभव के लिए उदाहरणों के साथ ग # में उफ़ अवधारणाएँ

कार्यात्मक आवश्यकताओं से गैर-कार्यात्मक आवश्यकताएं प्राप्त करना

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

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

(1) गैर-कार्यात्मक आवश्यकताएं एकत्रित करना:

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

# 2) गैर-कार्यात्मक आवश्यकताएं वर्गीकरण:

अगला चरण गैर-कार्यात्मक आवश्यकताओं का वर्गीकरण है जिसे हमने प्रश्नों के माध्यम से पहचाना है। इस स्तर पर, हम संभावित उत्तर की जांच कर सकते हैं और संभव गैर-कार्यात्मक श्रेणियों या विभिन्न गुणों के उत्तरों को वर्गीकृत कर सकते हैं।

नीचे दी गई छवि में आप उत्तर से पहचाने जाने वाले संभावित गुण देख सकते हैं।

कार्यात्मक बनाम गैर कार्यात्मक आवश्यकताएं

हमने पहले ही देखा है कि कार्यात्मक और गैर-कार्यात्मक आवश्यकताएं क्या हैं और वे कैसे व्युत्पन्न हैं। आइए हम कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं के बीच प्रमुख अंतरों पर एक नज़र डालें।

निष्कर्ष

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

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

अनुशंसित पाठ

• सॉफ़्टवेयर आवश्यकताएँ विशिष्टता (SRS) का परीक्षण कैसे करें?
• कार्यात्मक परीक्षण बनाम गैर-कार्यात्मक परीक्षण
• आवश्यकताओं के बिना किसी एप्लिकेशन का परीक्षण कैसे करें?
• एसडीएलसी में आवश्यकता विश्लेषण और सभा क्या है?
• आवश्यकताओं प्रबंधन में 5 घातक गलतियाँ और उन्हें कैसे काबू करें
• कार्यात्मक आवश्यकताओं और गैर कार्यात्मक आवश्यकताओं की विशेषताएं
• आवश्यकताएं कैसे बनाएं ट्रैसेबिलिटी मैट्रिक्स (RTM): उदाहरण और नमूना टेम्पलेट
• शीर्ष 20+ सर्वश्रेष्ठ आवश्यकताएँ प्रबंधन उपकरण (पूरी सूची)