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

Question

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

यह हमारे एक वरिष्ठ द्वारा वापस भेजा गया था, जो कि गलत था और जिसे हर आवश्यकता में उपयोग किया जाना चाहिए।

क्या मैं यहाँ गलत हूँ और हर आवश्यकता में Shall का उपयोग किया जाना चाहिए। मुझे लगता है कि वापस करने के लिए कुछ भी नहीं मिल रहा है।

Comments

हम हर उस आवश्यकता का उपयोग करते हैं जो अनिवार्य है। लेकिन "एक ही बात" का अर्थ "कम" होना चाहिए। यह भी देखें tynerblain.com/blog/2009/04/22/dont-use-shall

— रॉबर्ट हार्वे

क्या आप शायद RFC में MUSTबनाम के बारे में सोच SHOULDरहे हैं? ietf.org/rfc/rfc2119.txt

— user10326

यह भी देखें plainlanguage.gov/howto/wordsuggestions/shallmust.cfm

— Arseni Mourzenko

एह, पार्टी-पॉपर होने के लिए नहीं, लेकिन जब आप सभी सही स्थिति में सही शब्द का उपयोग करते हैं तो आप क्या जीत रहे हैं?

— पीटर

आवश्यकताएँ दस्तावेज़ीकरण: विल बनाम शल

— केमन सेप

Answer 1

RFC 2119 " RFC में उपयोग के लिए प्रमुख शब्द आवश्यकता स्तर को इंगित करता है" आवश्यकताओं के विभिन्न शब्दों का क्या अर्थ है, इसकी बारीकियों में जाता है।

इस दस्तावेज़ में "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLULD", "SHOULD NOT", "RECOMMENDED", "MAY", और "OPTIONAL" प्रमुख शब्द हैं। आरएफसी 2119 में वर्णित के रूप में व्याख्या की जाएगी।

इस दस्तावेज़ से:

• MUSTके बराबर है REQUIREDऔर SHALLयह दर्शाता है कि परिभाषा एक परम आवश्यकता है।
• MUST NOTके बराबर है SHALL NOTऔर इंगित करता है कि यह ऐनक का पूर्ण निषेध है।
• SHOULDके बराबर है RECOMMENDEDवहाँ वैध कारण एक विशेष आवश्यकता की अनदेखी करने के हैं, लेकिन निहितार्थ तौला जाना करने की जरूरत है कि इसका मतलब है।
• SHOULD NOTऔर NOT RECOMMENDEDइसका मतलब है कि एक विशेष व्यवहार स्वीकार्य या उपयोगी हो सकता है, लेकिन फिर से, निहितार्थ को तौलना चाहिए।
• MAYइसका मतलब है OPTIONALऔर यह आवश्यकता वास्तव में वैकल्पिक है। अलग-अलग प्रणालियों के साथ अंतर जो एक वैकल्पिक आवश्यकता को लागू कर सकते हैं या नहीं कर सकते हैं, किया जाना चाहिए।

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

Comments

ठोस जवाब; RFC खोदने के लिए सहारा

@ GlenH7 मुझे इसका पता था (मुझे 1 अप्रैल RFC पढ़ने में मज़ा आता है और कुछ हास्य 'चाहिए' और 'चाहिए' में हैं, और 2119 विकिपीडिया पेज पर भी ) मैंने इसे खोजा, इसे पाया, और फिर पढ़ा टिप्पणी मैं बनाने के बारे में था - दो से ऊपर यह फिर से आरएफसी था। तो इसे खोदने के लिए पूरी तरह से विशाल सहारा नहीं है ।

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

— टिम Lieberman

Answer 2

निश्चित नहीं है कि आप इस निष्कर्ष पर कहाँ आए हैं shallऔर mustप्रलेखन के अलग-अलग स्तरों पर हैं। यह एक बहुत ही मनमाना भेद है जो मेरे द्वारा ज्ञात किसी भी स्रोत द्वारा समर्थित नहीं है।

Shallऔर mustशाब्दिक समकक्ष हैं। यह एक कार्रवाई है जो आवश्यक है।

चाहे आप उपयोग करें shallया mustवास्तव में उस दस्तावेज़ के बाकी हिस्सों पर निर्भर करता है जिसे आप लिख रहे हैं और जो उस विशेष वाक्य के लिए व्याकरणिक समझ में आता है।

तो हाँ, आप गलत हैं। लेकिन आप shallइसके बजाय हमेशा उपयोग करने पर भी गलत हैं must। वे एक ही डिग्री के दायित्व का प्रतिनिधित्व करते हैं।

Comments

Shouldऔर mayकाफी समकक्ष नहीं हैं। वे दोनों वैकल्पिक सुविधाओं को दर्शाते हैं, लेकिन should, इसके विपरीत may, इसका मतलब है कि आपको इसे लागू नहीं करने के लिए एक अच्छा कारण होना चाहिए। मैं आपके साथ shallबनाम पर सहमत हूं must, हालांकि।

— कीथ थॉम्पसन

@KeithThompson - यह एक अच्छी बात है, और आप सही हैं। मैंने जवाब से उस लाइन को खींच लिया।

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

— टिम लेबरमैन 20

मुझे लगता है कि मेरे पास मेरे सिर में नई वस्तु के रूप में एम्बेडेड होना चाहिए और कार्य के रूप में होना चाहिए।

— टिम लेबरमैन 20

@TimLieberman - यह चीजों को देखने का एक बुरा तरीका नहीं है, खासकर जब से यह विनिर्देशों की दो परतों को जोड़ता है। उपयोगी, वास्तव में, चूंकि कुछ लोक शब्दों के शब्दार्थ से भ्रमित हो जाते हैं। खासकर जब से मैंने प्रक्रिया डॉक्स तय किया है, जहां "चाहिए" अक्सर "चाहिए" के विकल्प के रूप में उपयोग नहीं किया जाता था। हालांकि, यह एक विशेष मानक के रूप में आवश्यक होने के लिए पर्याप्त उपयोगी नहीं है।

Answer 3

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

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

ध्यान दें कि DO-178 और DO-254 की व्युत्पन्न आवश्यकता वास्तव में एक ऐसी आवश्यकता है जो उच्च-स्तर की आवश्यकता से उत्पन्न नहीं हुई है । एक व्युत्पन्न आवश्यकताएं इसलिए अनिवार्य रूप से ट्रेसबिलिटी की एक नई श्रृंखला शुरू करती हैं।

DO-178 और DO-254 दोनों एविऑनिक्स सॉफ्टवेयर और इलेक्ट्रॉनिक्स विकास के लिए उपयोग किए जाने वाले वाणिज्यिक दिशानिर्देश दस्तावेज हैं, और केवल www.rtca.org से शुल्क के लिए उपलब्ध हैं ।