आवश्यकताओं और विशिष्टताओं के बीच अंतर क्या है? [बन्द है]


122

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

मैंने महसूस किया कि मुझे अंतर नहीं पता है; एक गूगल खोज बस मुझे और अधिक भ्रमित - ऐसा लगता है कुछ लोग कहते हैं कि विनिर्देशों हैं आवश्यकताओं, लेकिन एक निचले स्तर पर।


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

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

इसे इस तरह से सोचें (गंभीर रूप से बोलते हुए): आवश्यकताएँ = आवश्यकताएँ डॉक्टर और विनिर्देश = उपयोग-केस / डिज़ाइन डॉक्स
पीएचडी

4
आप उस व्यक्ति (व्यक्ति) से क्यों नहीं पूछते जो आप ये बना रहे हैं? केवल वे ही जवाब दे सकते हैं कि आपके विशिष्ट मामले में क्या आवश्यक है
२३:४६ में जाप

यह लेख पूरी तरह से उत्तर प्रदान करता है: ece.cmu.edu/~koopman/des_s99/requirements_specs
जुलिएन-एल

जवाबों:


129

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

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


4
क्या / कैसे ध्वनि के काटने सही है, एक तरह से; लेकिन भ्रामक, क्योंकि आप किसी कार्यक्रम के विनिर्देशन को भी देख सकते हैं कि यह क्या करना चाहिए, और यह कैसे किया जाना चाहिए। एक और कथात्मक pl (prolog और SQL) की तरह है, जिसमें आप राज्य है क्या नहीं कैसे । एक संकल्प यह है कि वे अमूर्त हैं, एक अभिभावक के साथ जो बताते हैं कि बच्चे क्या और कैसे (अंदर बनाम बाहर) बताते हैं । मैं आपके दूसरे दृश्य को बहुत पसंद करता हूं, जो कि "इसके लिए क्या है " बनाम "यह क्या है " अर्थात लाभ बनाम सुविधा के करीब है ।
13ren

मैं आमतौर पर आपसे सहमत होता हूं, लेकिन यह सिर्फ एक और राय है और सही जवाब नहीं। उदाहरण के लिए, विकी पेज फॉर रिक्वायरमेंट ( en.wikipedia.org/wiki/Requirement ) पर एक नज़र डालें । गैर-कार्यात्मक आवश्यकताएं हैं, जो परिभाषा के अनुसार तकनीकी टीम के लिए है। या वास्तुकला और बाधाओं की आवश्यकताओं, फिर से तकनीकी लेकिन अभी तक वे उन्हें 'विनिर्देशों' नहीं कहते हैं। मुझे लगता है कि इसका कोई सही जवाब नहीं है और यह हमेशा कंपनी से कंपनी और डेवलपर से डेवलपर के लिए 'धुंधली' होगी।
पहुंचें

1
A एडम वूयरल ’की उत्तर पुस्तिका पर एक नज़र डालें, मुझे लगता है कि पोस्ट किए गए प्रश्न का सबसे सटीक कथन है।
Jeach

1
@Jeach: "bellow" [sic] सापेक्ष है। यह इस समय इस पोस्ट के नीचे हो सकता है, लेकिन यह ऊपर जा सकता है, जिससे आपकी टिप्पणी समझने में कठिन हो जाएगी
ब्रायन ओकले

1
एक और परिप्रेक्ष्य .. विकिपीडिया चश्मा को "आवश्यकताओं का समूह" के रूप में परिभाषित करता है। इसका मतलब यह है कि एक युक्ति सिर्फ 1 आवश्यकता हो सकती है, s: = {r1}। ऐसा लगता है कि बोलचाल की "आवश्यकताएं" "उच्च-स्तरीय" आवश्यकताएं हैं, जबकि "तकनीकी चश्मा" निम्न-स्तर की आवश्यकताएं हैं, एक एलओडी चीज।
लांस पोलार्ड

38

आवश्यकताएँ दस्तावेज़ जो आवश्यक है - उन्हें यह निर्दिष्ट नहीं करना चाहिए कि कैसे, लेकिन क्या।

विनिर्देशों का दस्तावेज है कि आवश्यकताओं को कैसे प्राप्त किया जाए - उन्हें कैसे निर्दिष्ट करना चाहिए।

कई स्थानों पर ये दस्तावेज़ अलग-अलग नहीं होते हैं और इनका परस्पर उपयोग किया जाता है।


2
मेरी कंपनी में हम आम तौर पर आप के लिए "आवश्यकताओं विनिर्देश" शब्द का उपयोग करते हैं (आप निर्दिष्ट करते हैं, विवरण लिखें कि आप क्या कहते हैं), और कैसे (आप निर्दिष्ट करें, विवरण लिखें, कैसे आप के लिए "डिजाइन विनिर्देश" इसे लागू करने की योजना)।
जियोर्जियो

16

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

एक विनिर्देश एक दस्तावेज है जो एक सिस्टम या उत्पाद को निर्दिष्ट करता है, उदाहरण के लिए एक एफ -14 के लिए एक प्रमुख-आइटम विकास विनिर्देश। एक कल्पना में बहुत सारे खंड / सामग्री हैं: आवश्यकताएँ, परिभाषाएँ, संदर्भ दस्तावेज़, शब्दावली, सत्यापन जानकारी, आदि।

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

तो एक कल्पना आवश्यकताओं से भरा एक दस्तावेज है, साथ ही कुछ अन्य सहायक और सहायक जानकारी है।


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

2
एक वास्तविक इंजीनियर का इनपुट पाने के लिए हमेशा मददगार। धन्यवाद!
लेउडी

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

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

13

आवश्यकताएँ:

विभिन्न हितधारकों की संभवतः परस्पर विरोधी आवश्यकताओं को ध्यान में रखते हुए, एक नए या परिवर्तित उत्पाद के लिए मिलने वाली जरूरतों या शर्तों को निर्धारित करें।

विशेष विवरण:

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

उद्धरण "सिस्टम इंजीनियरिंग बुनियादी बातों * " से है।

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

* रक्षा अधिग्रहण विश्वविद्यालय प्रेस, 2001. पाठ का पीडीएफ संस्करण


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

6

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

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

इसलिए, मुख्य बिंदुओं में से एक यह है कि विनिर्देश लिखे जाने से पहले आवश्यकताएँ पहले आनी चाहिए।

(शब्दावली देखें - उत्पाद और समाधान - एक ही चीज लेकिन विभिन्न दृष्टिकोणों से ...)


1
मैं "उत्पाद" और "समाधान" शब्दों को स्वैप करूंगा, क्योंकि एक समाधान आमतौर पर ग्राहक की समस्या के संदर्भ में होता है, जबकि एक उत्पाद आमतौर पर विक्रेता (यानी तकनीकी कार्यान्वयनकर्ता) के संदर्भ में होता है। एक समान विपरीत लाभ / सुविधा है, जहां लाभ ग्राहक के संदर्भ में है (इसका उपयोग क्या है), और सुविधा कार्यान्वयन शर्तों में है (वास्तव में यह क्या है , इसलिए हम इसे बना सकते हैं)।
13ren

1
मैं आपकी बात देखता हूं, लेकिन मुझे लगता है कि या तो कोण पर्याप्त रूप से स्थिति का वर्णन करता है। मैंने यह देखा कि एक ग्राहक एक उत्पाद खरीद रहा होगा - जैसा कि आप एक दुकान पर जाते हैं। एक सॉफ्टवेयर विक्रेता तब अंतर्निहित समस्या के समाधान की पेशकश करेगा। अगर मुझे अपनी समस्या के समाधान के लिए खरीदारी करने जाना था, तो मैं शायद सोचूंगा, "मुझे एक उत्पाद की आवश्यकता है जो xyz करता है", न कि, "मुझे एबीसी की मेरी समस्या का समाधान चाहिए"। मुझे लगता है कि यह सिर्फ वरीयता का मामला है।
अरज

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

मैं ग्राहकों को "एक उत्पाद की तलाश" कर सकता हूं, जब एक स्थापित उत्पाद श्रेणी होती है - लेकिन वे इसे एक समस्या / आवश्यकता के समाधान के रूप में तलाशते हैं। विक्रेता अपने उत्पादों को "समाधान" के रूप में विपणन करते हैं - क्योंकि वे ग्राहकों से संवाद कर रहे हैं (जिनके पास समाधानों की आवश्यकता है)। उत्पाद का निर्माण करते समय (स्वयं वस्तु और उसकी विशेषताएं, न कि वे उन्हें क्यों बना रहे हैं)। एक तर्क यह है कि एक समस्या के बहुत अलग समाधान हो सकते हैं - लेकिन एक उत्पाद एक विशिष्ट चीज है।
13ren

[यह समझाते हुए कि दो टिप्पणियाँ क्यों]: SO टिप्पणियां एक ऐसी पीड़ा हैं - "रिटर्न" मारने से टिप्पणी सबमिट हो जाएगी, भले ही यह एक बहु-पंक्ति टेक्स्टारिया हो। और यदि आप इसे समाप्त करने के लिए 5 मिनट से अधिक समय लेते हैं, तो यह संपादन को स्वीकार नहीं करेगा। इसलिए आपको इसे दूसरी टिप्पणी के रूप में प्रस्तुत करना होगा। मैं केवल लंबाई में फिट होने के लिए संपादन कर रहा था। आह । अगली बार जब मैं इसे पहली बार में दो टिप्पणियाँ फैलाऊंगा ... [वैसे भी, मैं मानता हूं कि देखने का बिंदु - खरीदार / विक्रेता - मुख्य अंतर है। मैं आपकी शब्दावली से परेशान हूँ, लेकिन मुझे लगता है कि यह मेरी समझ को गहरा करने की कोशिश करता है कि क्यों।]
13ren

4

आवश्यकता - सिस्टम या सबसिस्टम को क्या करना चाहिए (करना चाहिए)।

विशिष्टता - घटक, सबसिस्टम या सिस्टम क्या है।

यह चिकित्सा उपकरण निर्माण उद्योग में महत्वपूर्ण है क्योंकि आपको अपनी विशिष्टताओं (इनपुट्स) के विरुद्ध सत्यापन का संचालन करना चाहिए ताकि यह प्रदर्शित हो सके कि आपके पास वैध विनिर्देशन (आउटपुट) हैं। इस उद्योग में विशिष्ट नुकसान यह है कि कंपनियां (1) आवश्यकताओं को परिभाषित करना भूल जाती हैं (क्योंकि वे आवश्यकता बनाम कल्पना के बीच के अंतर को नहीं समझती हैं); (2) केवल विशिष्टताओं के खिलाफ आचरण का सत्यापन और (3) यह आश्वासन न दें कि आवश्यकताओं का सटीक रूप से उप-प्रक्रिया और घटक विनिर्देशों में अनुवाद किया जा रहा है।

एक बार यह सब पूरा हो जाने के बाद, आपको तब उत्पाद की प्रयोक्ता की आवश्यकताओं को पूरा करना होगा।


3

शायद भ्रम यह है कि मैंने विशिष्टताओं को व्यावसायिक आवश्यकता विनिर्देश दस्तावेजों या IEEE मानक SRS (सॉफ़्टवेयर आवश्यकता विशिष्टता) दस्तावेज़ों के संदर्भ में सुना है।

IEEE मानक SRS टेम्प्लेट उदाहरण

मैं भी सुना है अवधि विनिर्देशों के लिए अधिक अनौपचारिक उल्लेख तकनीकी विनिर्देश जो डिजाइन फैसले और एक कार्यान्वयन योजना की व्याख्या।

संपादित करें: मैंने अभी देखा कि लिंक गलत है ... मैं शीघ्र ही एक सही लिंक पोस्ट करूँगा।


1
SRS शब्द पर अच्छी बात!
लेउडी

2
लिंक अब पूरी तरह से टूट गया है। मुझे यकीन नहीं है कि इसने क्या इंगित किया था और न ही वहाँ से बाहर क्या सामग्री को इंगित करना चाहिए

3

एक विनिर्देश एक आवश्यकता है जो व्यवहार्यता से गुजरती है और लागू होने के लिए तैयार है। यह एक आवश्यकता है जो डिजाइन चरण में विकसित हुई है।

दूसरे शब्दों में:

  • एक आवश्यकता है व्यवहार (या गैर-व्यवहार) "जैसा कि नियोजित" या "जैसी इच्छा"
  • एक विनिर्देश व्यवहार है (या गैर-व्यवहार) "बनाया जाना" या "जैसा बनाया गया"

उदाहरण:

  • आवश्यकता: 1. उपयोगकर्ता ओके बटन दबाता है 2. सिस्टम प्रिंट करता है
  • विनिर्देश: 1. उपयोगकर्ता ओके बटन दबाता है 2. सिस्टम प्रिंट करता है

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

अंतिम रूप में निर्मित प्रलेखन में, आप आमतौर पर "आवश्यकता" के बजाय "विनिर्देश" शब्द पाएंगे, क्योंकि आवश्यकताओं को विनिर्देशों में परिवर्तित कर दिया गया है।

टिप्पणी: ऊपर दिए गए उदाहरण में डिजाइन तत्व शामिल हैं, क्योंकि डिजाइन की कमी है।


0

आवश्यकताएँ आवेदन क्या है

Specifcations हैं कि कैसे आवेदन यह क्या करता है।

उन्हें ओर्थोगोनल होना चाहिए!

उत्पाद प्रबंधक आवश्यकताओं को लिखते हैं, हेड इंजीनियर चश्मा लिखते हैं।


2
मुझे यकीन नहीं है कि वे कम से कम अभ्यास में पूरी तरह से ऑर्थोगोनल हैं। दुर्भाग्य से बहुत ग्रे है।
लेवूड

वे केवल ग्रे हैं यदि आप संशोधक को छोड़ देते हैं - व्यवसाय की आवश्यकताएं, कार्यात्मक आवश्यकताएं, गैर-कार्यात्मक आवश्यकताएं सिस्टम की क्षमता का उल्लेख करती हैं (यह क्या करता है)। तकनीकी विनिर्देश व्यावसायिक आवश्यकताओं के लिए रूढ़िवादी हैं (यह कैसे करता है)।
ब्रायन 'बीजे' हॉफपॉयर जूनियर

0

एक तरीका, शायद इसे देखने का सही तरीका नहीं है:

आवश्यकताएं ऐसी चीजें (क्षमताएं, विशेषताएं, व्यवहार, आदि) हैं जो उपयोगकर्ता को मूल्य प्रदान करती हैं। इंटर्नल से चिंतित नहीं; केवल बॉक्स के इनपुट और आउटपुट (और शायद आकार, आकार और रंग) यहां महत्वपूर्ण हैं।

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


क्या यह केवल आपकी राय है या आप इसे किसी तरह वापस कर सकते हैं?
gnat

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

0

अपने शोध में, मैंने पाया है कि पेटेंट और हाउस कंस्ट्रक्शन (एक अनुबंध के हिस्से के रूप में) के लिए उपयोग किया जाता है।

Webster के Unabridged Dictionary (3rd New Int'l Ed।) से एक आवश्यकता की परिभाषा है।

क) ऐसी चीज जो वांछित या आवश्यक हो: आवश्यकता बी) किसी चीज के लिए या मांग की गई: एक अपेक्षित या आवश्यक शर्त: एक आवश्यक गुणवत्ता, पाठ्यक्रम, या प्रशिक्षण का प्रकार।

मुझे लगता है कि उपरोक्त उन्हें स्पष्ट रूप से अलग दिखाता है। मुझे लगता है कि आप कल्पना के निचले स्तर की आवश्यकताओं को बुला सकते हैं, लेकिन मुझे लगता है कि यह शब्द की आवश्यकता imho का विकृति है।


0

एक पिछली कंपनी में वाणिज्यिक उत्पाद बनाने के लिए हमारे पास निम्नलिखित अंतर थे:

आवश्यकताएँ हैं कि सिस्टम को क्या करना चाहिए। वे निचले स्तर, विस्तृत आवश्यकताएं हो सकते हैं, और वे कार्यात्मक या गैर कार्यात्मक हो सकते हैं।

विनिर्देशों वे चीजें हैं जो सिस्टम वास्तव में निर्मित होती हैं। उदाहरण के लिए, आपके पास एक आवश्यकता हो सकती है जो कहती है कि सिस्टम में X -10 ° C पर व्यवहार X होगा। सिस्टम का वास्तविक विनिर्देश यह हो सकता है कि सिस्टम X को -5 ° C पर करता है; यह संभावित ग्राहकों को भेजी गई शीट में होगा जब वे सिस्टम खरीदना चाहते हैं।

एनबी इस मामले में विनिर्देश आवश्यकता के बराबर नहीं है।


-1

सोचिए, आप किसी जमीन पर ऊंची इमारत बनाने जा रहे हैं।

अब आपको शुरू करने से पहले आवश्यकताओं पर विचार करना होगा, जैसे:

  1. आर्किटेक्चर या डिज़ाइन इंजीनियर
  2. मृदा परीक्षण इंजीनियर
  3. विंड प्रेशर टेस्ट टीम
  4. विनाशक
  5. खान में काम करनेवाला
  6. मैन पावर
  7. जलापूर्ति
  8. रहने वाले / आराम क्षेत्र के कार्यकर्ता
  9. पर्याप्त निधि
  10. परियोजना प्रबंधन
  11. गुणवत्ता प्रबंधन
  12. सुरक्षा और सुरक्षा नियंत्रण

आदि।

अब उच्च सामग्री के निर्माण के लिए उपरोक्त सामग्री आवश्यकताओं का हिस्सा है। उपरोक्त टीम से, आपको तकनीकी परिणाम मिलते हैं, जिसे वे पेशे के हिस्से के रूप में रखते हैं।

यह वास्तव में सॉफ्टवेयर उद्योग में क्या हो रहा है, तकनीकी विनिर्देश बनाने के लिए ज्ञान प्रदान करने के लिए शामिल पेशेवर लोगों का एक समूह, जैसे कि कोई यूआई डिजाइन, ओओ डिजाइन, डेटाबेस डिजाइन, ग्राफिक डिजाइन, टेस्ट केस डिजाइन, कोडिंग, एकीकरण पर काम करता है। , तैनाती टीम आदि।

उपरोक्त पैरा हैंडबुक का हिस्सा होगा, जिसे आप तकनीकी विनिर्देश कह सकते हैं।


1
मुझे लगता है कि आप संसाधनों के साथ आवश्यकताओं को भ्रमित कर रहे हैं ( en.wikipedia.org/wiki/Resource_%28project_management/29 )।
जे एलस्टन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.