एक सॉफ्टवेयर आवश्यकता विनिर्देश लेखन


15

विनिर्देशन लिखने के बारे में मेरे कुछ प्रश्न हैं और वे हैं:

  1. जब हम एक सॉफ़्टवेयर विनिर्देश लिखते हैं, तो "उपयोगकर्ता की आवश्यकताओं की परिभाषा" विषय के तहत हमें केवल "फ़ंक्शंस" और "बाधाओं" को निर्दिष्ट करना होगा?

  2. क्या "यूजर इंटरफेस" "कार्यों" या "बाधाओं" में आता है?

  3. एक प्रमुख प्रमुख क्षेत्र (आवश्यकताएं) एक सॉफ्टवेयर को किस प्रकार (जैसे यूआई) में तोड़ा जा सकता है?


यह लेख सहायक हो सकता है: चश्मा में 10 विशिष्ट गलतियाँ
yegor256

जवाबों:


16

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

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

यहां टेम्प्लेट के बारे में अधिक जानकारी के लिए एक लिंक दिया गया है:

http://www.volere.co.uk/template.htm

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

इसमें इसके अनुभागों का सारांश दिया गया है (उपरोक्त लिंक से उद्धृत):

  1. परियोजना का उद्देश्य

  2. द स्टेकहोल्डर

  3. अनिवार्य बाधाएं

  4. नामकरण परंपराएँ और परिभाषाएँ

  5. प्रासंगिक तथ्य और धारणाएँ

  6. कार्य का दायरा

  7. व्यवसाय डेटा मॉडल और डेटा शब्दकोश

  8. उत्पाद का दायरा

  9. कार्यात्मक और डेटा आवश्यकताएँ

  10. देखो और आवश्यकताओं को महसूस करो

  11. प्रयोज्यता और मानवता आवश्यकताएँ

  12. प्रदर्शन संबंधी जरूरतें

  13. संचालन और पर्यावरणीय आवश्यकताएँ

  14. स्थिरता और समर्थन आवश्यकताएँ

  15. सुरक्षा आवश्यकताएँ

  16. सांस्कृतिक और राजनीतिक आवश्यकताएं

  17. कानूनी आवश्यकताएं

  18. खुले मामले

  19. ऑफ-द-शेल्फ समाधान

  20. नई समस्याएं

  21. कार्य

  22. नए उत्पाद के लिए प्रवासन

  23. जोखिम

  24. लागत

  25. उपयोगकर्ता प्रलेखन और प्रशिक्षण

  26. प्रतीक्षालय

  27. समाधान के लिए विचार


10

मैं सॉफ्टवेयर पर जोएल को पढ़ने की सलाह देता हूं। मुझे यकीन नहीं है कि यह आपके विशिष्ट प्रश्नों का उत्तर देता है, लेकिन उसके पास कार्यात्मक विशेषताओं को लिखने के लिए इसका एक उत्कृष्ट अवलोकन है :

एक कल्पना का सबसे महत्वपूर्ण कार्य कार्यक्रम को डिजाइन करना है । यहां तक ​​कि अगर आप अपने आप से सभी कोड पर काम कर रहे हैं, और आप अपने स्वयं के लाभ के लिए पूरी तरह से एक युक्ति लिखते हैं, तो कल्पना को लिखने का कार्य - यह वर्णन करते हुए कि कार्यक्रम मिनट में कैसे काम करता है - आपको वास्तव में कार्यक्रम को डिजाइन करने के लिए मजबूर करेगा ...

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

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

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

एक विस्तृत कल्पना के बिना, शेड्यूल बनाना असंभव है ... बहुत सारे प्रोग्रामिंग संगठनों में, हर बार एक डिज़ाइन बहस होती है, कोई भी कभी भी निर्णय लेने का प्रबंधन नहीं करता है, आमतौर पर राजनीतिक कारणों से। इसलिए प्रोग्रामर केवल अनियंत्रित सामान पर काम करते हैं। जैसे ही समय बढ़ता है, सभी कठिन निर्णय अंत तक धकेल दिए जाते हैं ... एक युक्ति लिखना उन सभी परेशान करने वाले डिजाइन निर्णयों को खत्म करने का एक शानदार तरीका है, बड़े और छोटे, जो आपके पास एक युक्ति नहीं है तो ढँक जाते हैं। ..


@ मुझे नहीं लगता कि लेख से उद्धरण आवश्यक है। यदि आप अंशों की अपनी पसंद को उजागर करना चाहते हैं, तो मेरा सुझाव है कि आप प्रश्न का अपना उत्तर दें।
जोनाथन स्वाइन ने

अपने उत्तर को पढ़ने देने पर विचार करें एक अन्य महल में है: जब एक उत्तर एक उत्तर नहीं है? "मुझे स्पष्ट होने दें: इस तरह की प्रतिक्रिया का उत्तर नहीं है । यदि आप इसे देखते हैं, तो इसे ध्वजांकित करें। मॉडरेटर, यदि आप इसे ध्वजांकित देखते हैं, तो इसे हटा दें "
gnat

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

6

जब हम एक सॉफ़्टवेयर विनिर्देश लिखते हैं, तो "उपयोगकर्ता की आवश्यकताओं की परिभाषा" विषय के तहत हमें केवल "फ़ंक्शंस" और "बाधाओं" को निर्दिष्ट करना होगा?

एक आवश्यकता दो चीजों का संयोजन है ...

  1. बात क्या करता है कार्यात्मक आवश्यकता।
  2. कितना अच्छा करता है। गैर कार्यात्मक आवश्यकता या "बाधा"

क्या "यूजर इंटरफेस" "कार्यों" या "बाधाओं" में आता है?

मैं कहूंगा कि "यूजर इंटरफेस" आवश्यकताओं की श्रेणी होगी जैसा कि आपने अपने अंतिम प्रश्न में पहचाना है।

एक प्रमुख प्रमुख क्षेत्र (आवश्यकताएं) एक सॉफ्टवेयर को किस प्रकार (जैसे यूआई) में तोड़ा जा सकता है?

यह सॉफ्टवेयर पर निर्भर करता है। आप सिस्टम के कुछ हिस्सों के आधार पर आवश्यकताओं को समूहीकृत कर सकते हैं या आप उन्हें उपयोग के मामले या व्यावसायिक आवश्यकता के आधार पर समूहित कर सकते हैं, जो कार्य पूरा कर रहे हैं।

बेशक यह सब आपके वास्तविक लक्ष्य के लिए गौण है जो सॉफ्टवेयर सिस्टम के स्पष्ट, स्पष्ट और परीक्षण योग्य विवरण को निर्धारित करना है।


4

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

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

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

प्रतिबंध:

  • "स्टार्टअप स्क्रीन दो बटन प्रदर्शित करेगी:" स्टार्ट ", और" स्टॉप "
  • "प्रदर्शन फ़ॉन्ट 10 बिंदु से छोटा नहीं होगा।"

कार्य:

  • "जब Startकुंजी दबाया जाता है, तो सॉफ्टवेयर WOPR के लिए एक टीसीपी / आईपी कनेक्शन स्थापित करेगा "

आपके उदाहरणों की आवश्यकताएं नहीं हैं, वे डिजाइन हैं। आवश्यकता को कैसे पूरा किया जाए इसकी बारीकियां एक डिजाइन निर्णय है, आवश्यकता नहीं। इस प्रकार, "दो बटन" एक डिजाइन निर्णय है। यह स्पष्ट हो जाता है जब आपको पता चलता है कि एक ही लक्ष्य को पूरा करने के कई अन्य वैध तरीके हैं (कुछ शुरू करें या बंद करें)। इस प्रकार, इसे एक आवश्यकता से अधिक बनाने के लिए आप कहेंगे "यूआई कुछ शुरू करने और रोकने के लिए एक साधन प्रदान करेगा"। लेकिन मैं और आगे जाऊंगा, क्योंकि UI का उपयोग करना भी एक डिजाइन निर्णय है। तो सिस्टम की आवश्यकता के लिए यह होगा "सिस्टम स्टार्ट एंड स्टॉप
डुंक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.