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


34

मैं कार्यात्मक या गैर-कार्यात्मक आवश्यकताओं के बारे में सोच रहा हूं। मुझे उन शर्तों के लिए बहुत सी अलग-अलग परिभाषाएँ मिली हैं और मैं अपनी आवश्यकता को उचित श्रेणी में नहीं रख सकता।

मैं उन आवश्यकताओं के बारे में सोच रहा हूं जो कुछ कार्रवाई से जुड़ी नहीं हैं या कुछ अतिरिक्त शर्तें हैं, उदाहरण के लिए:

  1. चयनित उपकरणों की सूची में, डिवाइस को दोहराया जा सकता है।
  2. डेटाबेस में कम से कम 100 आइटम होने चाहिए
  3. कुछ मूल्य की मुद्रा अमरीकी डालर में होनी चाहिए।
  4. वाट्स में डिवाइस का नाम और बिजली की खपत का मूल्य होना चाहिए।

क्या वे आवश्यकताएं कार्यात्मक या गैर-कार्यात्मक हैं?


4
मुझे लगता है कि "फंक्शनल" और "नॉन-फंक्शनल" के बीच का अंतर भ्रामक है और सॉफ्टवेयर को खराब संचालन के साथ छोड़ देता है। मैंने पाया है कि "एंड-यूज़र फीचर्स" और "ऑपरेशनल फीचर्स" के बारे में सोचने से बेहतर सॉफ्टवेयर बनते हैं : blog.softwareoperability.com/2013/04/08/… (मेरी पोस्ट)
मैथ्यू स्केल्टन

@MatthewSkelton मैं यह नहीं बता सका कि (2.) एक एन-यूज़र फ़ीचर है या ऑपरेशन फ़ीचर। एक "परीक्षण-सुविधा" होने लगता है।
मार्टिन थोमै

@moose - कुछ मापदंडों के भीतर DB के लिए / संचालित करने की आवश्यकता / दिए गए 100 आइटम एक परिचालन आवश्यकता से अधिक है, हालांकि यह प्रदर्शन को नीचा दिखाने पर अंतिम उपयोगकर्ता अनुभव को प्रभावित कर सकता है। अंततः, हमें संभवतः एफ और एनएफ में विभाजित होने में सक्षम होने के लिए ओपी में आवश्यकताओं पर थोड़ा और अधिक संदर्भ की आवश्यकता होगी, हालांकि - जैसा कि मैंने संकेत दिया है - मुझे लगता है कि यह किसी भी तरह से थोड़ा अंतर है :)
मैथ्यू स्केलेस्ट

जवाबों:


41

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

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

विकिपीडिया का संदर्भ लें : अधिक विवरण के लिए कार्यात्मक आवश्यकता

गैर-कार्यात्मक आवश्यकताएं ऐसी आवश्यकताएं हैं जो सिस्टम के इनपुट / आउटपुट व्यवहार का वर्णन नहीं करती हैं। ध्यान दें कि हम अभी भी आवश्यकताओं के बारे में बात कर रहे हैं , कार्यान्वयन विवरण नहीं , इसलिए सिर्फ इसलिए कि हम "गैर-कार्यात्मक" वाक्यांश का उपयोग कर रहे हैं इसका मतलब यह नहीं है कि उस खंड में कुछ भी उचित खेल नहीं है।

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

ये सभी क्रॉस-कटिंग चिंताएं हैं जो हर "सुविधा" को प्रभावित करती हैं फिर भी वास्तव में खुद को सुविधाएँ नहीं देती हैं; वे फीचर मेटाडेटा को अधिक पसंद कर रहे हैं, यह वर्णन करने में मदद नहीं कर रहे हैं कि क्या सिस्टम ऐसा करता है, बल्कि यह माना जाता है कि यह कितना अच्छा है। उस सादृश्य को बहुत दूर तक न ले जाएँ, हालाँकि - यह सिर्फ एक सादृश्य है।

गैर कार्यात्मक आवश्यकताओं हैं नहीं व्यक्तिपरक या हाथ से wavey, क्या यहाँ कुछ लोगों का सुझाव हो रहे हैं के विपरीत। वास्तव में, उन्हें वास्तव में उनसे जुड़ी एक कठिन मीट्रिक होनी चाहिए (यानी 100 एमएस से अधिक की प्रतिक्रिया समय)। एनएफ आवश्यकताओं को लागू करने वाले विवरण या कार्य भी नहीं हैं जैसे "ORM फ्रेमवर्क को अपग्रेड करना" - कोई सुराग नहीं जहां किसी को भी यह विचार मिलेगा।

अधिक विवरण विकिपीडिया पर: गैर-कार्यात्मक आवश्यकता


प्रश्न में उदाहरणों को विशेष रूप से संबोधित करने के लिए:

  1. चयनित उपकरणों की सूची में, डिवाइस को दोहराया जा सकता है।

    • स्पष्ट रूप से एक कार्यात्मक आवश्यकता। वर्णन करता है कि सिस्टम का आउटपुट कैसा दिखता है।
  2. डेटाबेस में कम से कम 100 आइटम होने चाहिए

    • एक व्यावसायिक नियम की तरह लगता है, इसलिए एक कार्यात्मक आवश्यकता भी है। हालाँकि, यह अधूरा लगता है। इस नियम का क्या कारण है? यदि डेटाबेस में 100 से कम आइटम हैं तो क्या होगा / होना चाहिए?
  3. कुछ मूल्य की मुद्रा अमरीकी डालर में होनी चाहिए।

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

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

अच्छा! मैं जो बात जोड़ूंगा वह यह है कि कार्यात्मक आवश्यकताओं को केवल बाहरी वातावरण के साथ बातचीत से निपटने की आवश्यकता नहीं है (एक संबंधित अवधारणा अन्य प्रणालियों के साथ "इंटरफ़ेस आवश्यकताएं" हैं)। इसके लिए एक प्रतिउत्तर यह होगा कि "सिस्टम को प्रत्येक 60 मिनट में उपयोगकर्ताओं के डेटाबेस को अनुक्रमित करना चाहिए"। यह स्पष्ट रूप से आंतरिक है।
अराम कोचरन

2
@AramKocharyan: यह एक कार्यात्मक आवश्यकता नहीं है। स्पष्ट रूप से वहाँ एक ग्राहक SLA वहाँ कहीं छिपा है, और वह कार्यात्मक आवश्यकता है। "संपर्क अपडेट को समय पर ग्राहक सेवा / विपणन का समर्थन करने के लिए 60 मिनट के भीतर संसाधित किया जाना चाहिए" - यह एक आंतरिक, कार्यात्मक आवश्यकता है। "उपयोगकर्ताओं के डेटाबेस को अनुक्रमित करें" यह एक आवश्यकता नहीं है, यह एक कार्यान्वयन है; उदाहरण के लिए, एसएलए ने कहा कि मिलने का एक अन्य तरीका रियलटाइम बैकग्राउंड इंडेक्सिंग का उपयोग करना हो सकता है, या किसी सर्विस ब्रोकर या बस और प्रोसेसिंग अपडेट को निकट-रीयलटाइम में उपयोग करके पूरी तरह से इंडेक्सिंग की आवश्यकता को समाप्त करना हो सकता है।
Aaronaught

+1! गैर-कार्यात्मक आवश्यकताओं की विषय-वस्तु के बारे में, यह इंगित करने के लिए पर्याप्त हो सकता है कि वे बहुत ठोस RESTful वास्तुकला के मूल में हैं en.wikipedia.org/wiki/…
fr_andres SupportsMonicaCellio

18

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


एक गैर-कार्यात्मक आवश्यकता "एक गुणवत्ता या संपत्ति है जो उत्पाद के पास होनी चाहिए" is । जेम्स टेलर बताता है कि एक गैर-कार्यात्मक आवश्यकता "[...] [फिर भी] एक आवश्यकता है, और यह ग्राहक के लिए महत्वपूर्ण है-कभी-कभी एक कार्यात्मक आवश्यकता से भी अधिक महत्वपूर्ण" । वह फिर दो उदाहरण देता है: उत्पाद का लोगो, और उपकरण की सटीकता और विश्वसनीयता। उन दोनों उदाहरणों से पता चलता है कि:

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

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

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

तो, आइए कुछ उदाहरण देखें।

  1. सॉफ्टवेयर उत्पाद अंतिम उपयोगकर्ता के लिए उत्तरदायी है।

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

  2. उपयोगकर्ता के आँकड़ों को पुनः लोड करने का समय 100 एमएस से 90% कम है। जब परिशिष्ट G भाग 2 में निर्दिष्ट प्रदर्शन और सीपीयू के लिए 10% से नीचे लोड, मेमोरी के लिए 50% से नीचे और कोई सक्रिय आर / डब्ल्यू डिस्क संचालन के साथ मशीन पर परीक्षण नहीं किया गया।

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

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

क्या यह एक गैर-कार्यात्मक आवश्यकता है? यह है। यह एक संपत्ति को निर्दिष्ट करता है जो एक उत्पाद होना चाहिए, अर्थात प्रतिशत सीमा को देखते हुए अधिकतम / औसत प्रतिक्रिया समय।

  3. आवेदन C # में लिखा गया है।

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

  4. उत्पाद का C # कोडबेस Microsoft न्यूनतम अनुशंसित नियम और Microsoft वैश्वीकरण नियम का अनुसरण करता है।

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

  5. आवेदन की मुख्य विंडो में गुलाबी (#fcc) भरे हुए हलकों के साथ एक नीला (# 00f) 10px बॉर्डर है, उन सर्कल को सीमा के अंदरूनी किनारे पर रखा जा रहा है और व्यास 3px है, जो एक दूसरे से 20px अलग हैं।

यह एक आवश्यकता है, और एक गैर-कार्यात्मक है। यह कुछ ऐसा निर्दिष्ट करता है जिसे हम सत्यापन परीक्षण के दौरान परीक्षण कर सकते हैं, और यह उत्पाद की एक संपत्ति को निर्दिष्ट करता है, न कि उस उत्पाद को जो करने का इरादा है।

  6. वाहन ट्रैकिंग सिस्टम tracking 0.016 मील प्रति घंटे की सटीकता के साथ गति को मापता है।

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

  7. व्हीकल ट्रैकिंग सिस्टम वाहन की गति को मापता है।

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

  8. वेबसाइट के पन्नों में 850 ms हैं। लोड करने के लिए।

यह कोई आवश्यकता नहीं है। एक होने की कोशिश करता है, लेकिन पूरी तरह से अमान्य है। आप यह कैसे करेंगे? कौन से पृष्ठ? सब? क्वाड-कोर क्लाइंट मशीन पर एक स्थानीय 1Gbps नेटवर्क के माध्यम से और SSDs के साथ आठ-कोर सर्वर का उपयोग 2% या पुराने और भद्दे लैपटॉप के एक मॉडेम के माध्यम से किया जाता है, जबकि वेबसाइट को 99% पर उपयोग किए जाने वाले एक छोटे सर्वर द्वारा होस्ट किया जा रहा है। ? "लोड करने के लिए" का क्या अर्थ है? क्या इसका मतलब पेज डाउनलोड करना है? इसे डाउनलोड और प्रदर्शित करना? कुछ बड़े डेटा के साथ POST अनुरोध भेजना, फिर प्रतिक्रिया लोड करना और उसे प्रदर्शित करना?

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


Ies प्रबंध सूचना प्रौद्योगिकी परियोजनाएं: सॉफ्टवेयर, हार्डवेयर, और एकीकरण पहल, जेम्स टेलर, आईएसबीएन के लिए परियोजना प्रबंधन रणनीतियों को लागू करना: 0814408117।


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

@ ईमद करीम: आप सही कह रहे हैं। मैं खुद को विशुद्ध रूप से तकनीकी आवश्यकताओं तक सीमित करता हूं, अर्थात डेवलपर्स और क्यूए द्वारा उपयोग की जाने वाली आवश्यकताएं। व्यापार विश्लेषकों के लिए, चीजें थोड़ी अलग हैं, और कुछ तत्व जो मैंने आवश्यकताओं के रूप में योग्य नहीं हैं, वास्तव में पूरी तरह से मान्य होंगे।
बजे आर्सेनी मौरज़ेंको

मैं तर्क देता हूं "आवेदन C # में लिखा गया है।" एक बाधा है, एक कार्यात्मक आवश्यकता नहीं है, क्योंकि यह प्रणाली के व्यवहार का वर्णन नहीं करता है, लेकिन समाधान स्थान के लिए सीमा का वर्णन करता है।
अराम कोचरन

@AramKocharyan: यही कारण है कि मैंने कहा कि हम नहीं जानते कि क्या यह कथन एक आवश्यकता है।
आर्सेनी मूरज़ेंको

3

एक कार्यात्मक आवश्यकता प्रणाली के साथ बातचीत करने के परिणाम का वर्णन करती है (सिस्टम दी गई स्थितियों में क्या करता है), जबकि गैर-कार्यात्मक आवश्यकता आमतौर पर प्रदर्शन, क्षमता, प्रतिक्रिया समय आदि की बारीकियों को संदर्भित करती है ... चीजें जो कार्यक्षमता का प्रतिनिधित्व नहीं करती हैं, एक प्रणाली में प्रक्रिया, या एक बातचीत का परिणाम है।

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

- यूआई लॉक नहीं होना चाहिए, जबकि पासा का एनीमेशन चल रहा है।

उपयोगकर्ता की आवश्यकताएं आमतौर पर विशिष्ट यूआई आवश्यकताएं होती हैं, जो कि संदर्भ के आधार पर कार्यात्मक या गैर-कार्यात्मक होंगी, जबकि सिस्टम आवश्यकताएं (समवर्ती उपयोगकर्ता क्षमता, उदाहरण के लिए) आमतौर पर गैर-कार्यात्मक होती हैं।


2

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

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

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

एक अंतिम बिंदु - यदि आप अभी तक एक "ility" के उद्देश्य माप के साथ नहीं आ सकते हैं, तो इसका मतलब यह नहीं है कि ग्राहक को इसकी आवश्यकता नहीं है। अस्पष्ट! = अनावश्यक। हालांकि, इसका मतलब यह हो सकता है कि हमें ऐसी चीजों को मापने के लिए बेहतर तरीके विकसित करने की आवश्यकता है, गैर-कार्यात्मक आवश्यकताओं को बढ़ा-चढ़ाकर परिष्कृत करना, या उन तरीकों (अनुबंध आदि) में अनुबंध करना जो हर चीज के लिए सामने वाले उद्देश्य उपायों के बिना काम कर सकते हैं।


0

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

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

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


-1

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

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


सूचीबद्ध उदाहरण आपको व्यावसायिक नियमों के समान क्यों लगते हैं?
gnat

-4

एक कार्यात्मक आवश्यकता आमतौर पर कुछ ऐसी प्रणाली है जो सिस्टम कर सकता है या करेगा। इसे एक कार्रवाई (एक नकारात्मक परिणाम के) के रूप में व्यक्त किया जा सकता है। एक गैर fucntional आवश्यकता कुछ है कि ग्राहक / अंत उपयोगकर्ता के बारे में परवाह नहीं है, और परिणाम को प्रभावित नहीं करता है - जैसे
- विंडोज गुलाबी डॉट्स के साथ एक नीले रंग की सीमा होगी। - प्रोग्राम जावा में लिखा जाएगा
- कोडिंग मानकों, विधियों और प्रक्रिया के साथ कुछ भी करने के लिए।

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

सारांश में - अगर ग्राहक इसकी परवाह करता है, तो यह एक कार्यात्मक आवश्यकता है, अन्यथा यह एक गैर-कार्यात्मक आवश्यकता है या संभवतः एक आवश्यकता भी नहीं है।


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

इसके अलावा, गैर-कवक को "विकास" (डेवलपर्स देखभाल, जैसे रखरखाव) और "परिचालन" (उपयोगकर्ताओं की देखभाल, उदाहरण के लिए प्रयोज्य) गुणों में तोड़ा जा सकता है
अराम कोचरन

-4

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.