2008-10-09 16 views
7

आवश्यकता विनिर्देशों की समीक्षा करते समय (जिसमें कार्यात्मक, गैर-कार्यात्मक आवश्यकताओं, बाधाएं इत्यादि शामिल हैं) हालांकि छोटे या बड़े लेखकों द्वारा किए गए "घातक पाप" क्या हैं?आवश्यकता विनिर्देशों की समीक्षा करते समय क्या "घातक पाप" को संबोधित करने की आवश्यकता है?

(गंभीरता को कम करने के क्रम में) 7 से अधिक नहीं सबसे आवश्यक चीजें प्रदान करें कि किया जा रहा है (या नहीं किया) आवश्यकताओं विनिर्देश में सॉफ्टवेयर उत्पाद की गुणवत्ता पर प्रतिकूल प्रभाव हो। 7 से कम बिल्कुल ठीक है।

उत्तर

12

ठीक है खोजने के लिए नहीं है और जहां है, यह 7 की तुलना में अधिक है, लेकिन अच्छे आवश्यकताओं में निम्नलिखित विशेषताएं होनी:

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

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

+0

सूची बहुत ठोस लगती है। क्या आपने इसे एक पुस्तक/यूआरएल से लिया था? –

+0

मैंने इसे एक दस्तावेज़ से लिया जो मैंने वर्षों में संकलित किया और संदर्भ के रूप में उपयोग किया। मुझे शायद अपने दस्तावेज़ में मूल स्रोतों का हवाला देना चाहिए था, लेकिन इनमें से अधिकतर 'नेट' से पहले आए थे और मैंने कभी कल्पना नहीं की थी, तो मैं इसे "प्रकाशन" कर दूंगा। –

+1

यह रॉन पैटन द्वारा 'सॉफ्टवेयर परीक्षण' पुस्तक से चोरी की गई है। –

1

आवश्यकताओं के विशिष्ट और क्या आवश्यक है के संबंध में स्पष्ट होना चाहिए, लेकिन कम तो कैसे आवश्यकताओं को पूरा करने पर होना चाहिए।

1

धारणाएं बनाना - दोबारा जांचें कि धारणा की तरह दिखने वाला कुछ भी वास्तव में सत्यापित किया गया है।

1

खराब शब्दों sentances कि एक से अधिक आवश्यकता शामिल पृष्ठ 42,43 पर जांच सूची की जांच करते हैं। किए गए रूप में उन्हें दूर करने के लिए उन्हें और अधिक स्पष्ट और आसान बनाने के लिए कहीं बाहर अलग करें।

1

आवश्यकताओं कि पूरा किया जा रहा के रूप में सत्यापित करने के लिए आसान नहीं हैं - एक रूप और अधिक आसानी से चिह्नित किया जा सकता है कि के रूप में मिले थे या नहीं जब की समीक्षा करने के लिए बदलें।

2

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

2

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

अपनी प्रक्रिया को नियंत्रित करने की कोशिश करने वाली आवश्यकताओं पर वापस पुश करें।

शुरुआत से स्पष्ट प्राथमिकता के लिए पूछें।

प्रत्येक आवश्यकता के लिए एक स्पष्ट स्वीकृति मानदंड पर जोर दें।

1

आवश्यकता निर्दिष्ट नहीं करती है कि चीज़ कौन/क्या करती है।

"The invoice is reconciled to the purchase order." 

क्या इसका मतलब यह है कि सिस्टम कुछ करता है, या उपयोगकर्ता?

1

सबसे बुरा एक मैं एक परियोजना मैं के लिए कोडित पर देखा है: -

The system shall interface to SAP as required. 

सबसे पहले, के साथ एक आवश्यकता के रूप में "आवश्यक" में यह बेवकूफ है। उस लाइन के लिए $ 400k खर्च होना चाहिए। ग्राहक ने इस पर इशारा करते हुए कहा कि यह कहता है कि आप ब्लाह, ब्लाह, ब्लाह करने जा रहे हैं।

1

कड़े से अधिक - यदि संभव हो तो प्रासंगिक सहनशीलता निर्दिष्ट करें।

1

संदिग्ध आवश्यकताएं खराब हैं।

अविश्वसनीय और अनिवार्य आवश्यकताएं डबल।

0

सब जानते हुए भी wikpedia requirements- http://en.wikipedia.org/wiki/Requirement#Good_requirements के लिए एक अच्छा सारांश है। मैं कहूंगा कि उन बिंदुओं की, सत्यापन की कमी सबसे आम है। जीवन में बड़ी तस्वीर को समझना महत्वपूर्ण है, हालांकि, आपको अपनी आवश्यकताओं में स्पष्ट रूप से चीजों की वर्तनी करने की आवश्यकता है।सिस्टम जल्दी जवाब दिया जाएगा। इसके बजाए, सिस्टम 2 सेकंड से कम समय में सभी अनुरोधों का जवाब देगा।

1

स्वाभाविक रूप से, यह सब इस बात पर निर्भर करता है कि आपको किस प्रकार की आवश्यकता है। मैं ठेठ गुई या वेब अनुप्रयोग, बैच प्रक्रियाओं और

  • पहले standars रखो, प्रत्येक विनिर्देश में परिभाषित किए जाने की जरूरत नहीं है कि उन्हें
  • यह के रूप में संभव के रूप में छोटे बनाने के लिए इस्तेमाल कर रहा हूँ - शायद ही कभी एक एक 200 पृष्ठों दस्तावेज़ पढ़ सकते हैं और मन में सब कुछ
  • , विशिष्ट mesurable रहो, ठोस रख सकते
  • क्या उदाहरण (चित्र, लेखांकन लेखन)
  • funtction
  • पी inlcude का वर्णन से पहले उद्देश्य के बारे में बताएं erformance मानकों, लचीलापन standars, तैनाती निर्देश, संचालन के लिए प्रलेखन

मैं समीक्षक के लिए एक ही सलाह भी है की जरूरत: पता अपने विषय

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

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

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

'वीज़ल शब्द' से बचें - किसी भी भाषा जिसे इसके संदर्भ से कुचला जा सकता है और बुरा लगता है बुरा है।

यकीन है कि सब कुछ बिल्कुल स्पष्ट है: अस्पष्ट == बुरा बात (टीएम)

0

आप Requirement management और CMMI दस्तावेजों के कुछ पढ़ने की सोच सकते हैं।

Requirement Checklist पर जाएं और "अच्छी आवश्यकता के मानदंड" के लिए Google पर जाएं।

ये विशेष रूप से सॉफ्टवेयर विकास में सहायता प्रक्रियाओं को बनाने के लिए डिज़ाइन किए गए हैं।

संबंधित मुद्दे