सॉफ्टवेयर इंजीनियरिंग में कार्यात्मक आवश्यकता क्या है?

⚡ स्मार्ट सारांश

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

  • 📘 परिभाषा: एक कार्यात्मक आवश्यकता, जिसे कार्यात्मक विनिर्देश भी कहा जाता है, यह बताती है कि सिस्टम को क्या करना चाहिए - इनपुट, व्यवहार और आउटपुट, जिनका वर्णन उपयोगकर्ता या व्यावसायिक दृष्टिकोण से किया जाता है।
  • 📄 दस्तावेज़ का दायरा: एक कार्यात्मक आवश्यकता दस्तावेज़ में स्क्रीन संचालन, डेटा हैंडलिंग लॉजिक, रिपोर्ट, वर्कफ़्लो, अनुमतियाँ और नियामक अनुपालन शामिल होते हैं।
  • सामान्य प्रकार: लेनदेन प्रबंधन, व्यावसायिक नियम, रिपोर्टिंग, प्रशासनिक कार्य, प्राधिकरण स्तर, लेखापरीक्षा tracराजा, बाह्य इंटरफेस और कानूनी आवश्यकताएं।
  • 💡 उदाहरण: लॉगिन सत्यापन, बिक्री रिकॉर्डिंग, भूमिका-आधारित राजस्व अवलोकन, बैंकिंग एपीआई एकीकरण और अभिगम्यता अनुपालन, ये सभी कार्यात्मक आवश्यकताओं के अंतर्गत आते हैं।
  • 🆚 गैर-कार्यात्मक कंट्रास्ट: कार्यात्मक आवश्यकताएं यह बताती हैं कि कोई सिस्टम क्या करता है; गैर-कार्यात्मक आवश्यकताएं यह बताती हैं कि वह सिस्टम कितनी अच्छी तरह से काम करता है - प्रदर्शन, सुरक्षा और उपयोगिता के मामले में।
  • सर्वोत्तम प्रथाएं: आवश्यकताओं को सूक्ष्म, परीक्षण योग्य और व्यावसायिक उद्देश्य से संबंधित रखें, और साक्षात्कार और कार्यशालाओं के माध्यम से उन्हें प्राप्त करें।

सॉफ्टवेयर इंजीनियरिंग में कार्यात्मक आवश्यकता

कार्यात्मक आवश्यकता क्या है?

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

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

फंक्शनल रिक्वायरमेंट्स डॉक्यूमेंट में क्या शामिल करें

एक कार्यात्मक आवश्यकता दस्तावेज़ में निम्नलिखित बातें शामिल होनी चाहिए:

कार्यात्मक आवश्यकताओं का उदाहरण

कार्यात्मक आवश्यकताओं का उदाहरण

एक कार्यात्मक आवश्यकता दस्तावेज़ में आमतौर पर निम्नलिखित शामिल होते हैं:

  • प्रत्येक स्क्रीन पर किए गए कार्यों का विवरण
  • सिस्टम द्वारा लागू की जाने वाली डेटा हैंडलिंग लॉजिक
  • Descriptसिस्टम रिपोर्ट और अन्य आउटपुट के आयन
  • सिस्टम द्वारा किए जाने वाले वर्कफ़्लो के बारे में पूरी जानकारी
  • सिस्टम में डेटा बनाने, संशोधित करने या हटाने की अनुमति किसे है?
  • यह प्रणाली लागू नियामक और अनुपालन आवश्यकताओं को कैसे पूरा करती है

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

एक अच्छी तरह से लिखे गए कार्यात्मक आवश्यकताओं के दस्तावेज़ के मुख्य लाभ निम्नलिखित हैं:

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

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

कार्यात्मक आवश्यकताओं की सामान्य श्रेणियों में निम्नलिखित शामिल हैं:

  • लेन-देन प्रबंधन
  • व्यापार नियम
  • प्रमाणन आवश्यकताएँ
  • रिपोर्टिंग आवश्यकताएं
  • प्रशासनिक कार्य
  • प्राधिकरण स्तर
  • लेखा परीक्षा Tracking
  • बाहरी इंटरफेस
  • ऐतिहासिक डेटा प्रबंधन
  • कानूनी और नियामक आवश्यकताएँ

कार्यात्मक आवश्यकताओं के उदाहरण

नीचे कार्यात्मक आवश्यकताओं के व्यावहारिक उदाहरण दिए गए हैं:

  • यह सॉफ्टवेयर एबीसी संपर्क प्रबंधन प्रणाली के माध्यम से ग्राहकों का स्वचालित रूप से सत्यापन करेगा।
  • बिक्री प्रणाली उपयोगकर्ताओं को ग्राहक बिक्री दर्ज करने की अनुमति देगी।
  • एप्लिकेशन में सभी विंडो का बैकग्राउंड रंग नीला होगा, जिसका हेक्साडेसिमल RGB मान 0x0000FF होगा।
  • केवल प्रबंधकीय स्तर के कर्मचारियों को ही राजस्व डेटा देखने का अधिकार होगा।
  • यह सॉफ्टवेयर सिस्टम बैंकिंग एपीआई के साथ एकीकृत होगा।
  • सॉफ्टवेयर सिस्टम को निम्नलिखित मानदंडों को पूरा करना होगा। धारा 508 पहुँच-योग्यता आवश्यकताएँ.

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

कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं के बीच प्रमुख अंतर यहाँ दिए गए हैं। सॉफ्टवेयर इंजीनियरिंग:

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

कार्यात्मक आवश्यकताओं को लिखने के लिए सर्वोत्तम अभ्यास

फंक्शनल रिक्वायरमेंट्स डॉक्यूमेंट लिखने के लिए सबसे महत्वपूर्ण सर्वोत्तम अभ्यास निम्नलिखित हैं:

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

फंक्शनल रिक्वायरमेंट्स लिखते समय होने वाली आम गलतियाँ

फंक्शनल रिक्वायरमेंट्स डॉक्यूमेंट बनाते समय की जाने वाली सामान्य गलतियाँ इस प्रकार हैं:

  • अनावश्यक अतिरिक्त जानकारी जोड़ना जिससे डेवलपर्स भ्रमित हो जाते हैं
  • डेवलपर्स को फीचर बनाने के लिए आवश्यक विवरण को छोड़ देना।
  • मिश्रण के नियम, उदाहरण, स्कोरping कथनों या उद्देश्यों को स्वयं आवश्यकता में शामिल करना।
  • आवश्यकता को पूर्ण और सटीक रूप से बताने के लिए आवश्यक जानकारी को छोड़ देना।
  • परिवर्तन अनुरोध आने पर सही उत्तर खोजने के बजाय मौजूदा आवश्यकता का बचाव करना।
  • ऐसी लेखन आवश्यकताएं जो किसी उद्देश्य या सिद्धांत से मेल नहीं खातीं।

अक्सर पूछे जाने वाले प्रश्न

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

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

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

स्पष्ट कर्ता, "shall" शब्द और प्रत्येक कथन में एक परीक्षण योग्य क्रिया का प्रयोग करें। "fast" जैसे अस्पष्ट शब्दों से बचें और केवल एक व्यवहार को शामिल करें ताकि आवश्यकता को एक ही सफल या असफल जाँच से परखा जा सके।

ईएआरएस (Easy Approach to Requirements Syntax) पांच टेम्पलेट प्रदान करता है: सर्वव्यापी, इवेंट-ड्रिवन, स्टेट-ड्रिवन, वैकल्पिक फ़ीचर और अवांछित व्यवहार। प्रत्येक टेम्पलेट एक परीक्षण योग्य संरचना को बाध्य करता है, जैसे कि जब ट्रिगर होता है तो सिस्टम को प्रतिक्रिया देनी चाहिए।

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

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

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

इस पोस्ट को संक्षेप में इस प्रकार लिखें: