आवश्यकताएं इंजिनीयरिंग

From alpha
Jump to navigation Jump to search

आवश्यकताएं इंजीनियरिंग (आरई[1] आवश्यकता . को परिभाषित करने, दस्तावेजीकरण करने और बनाए रखने की प्रक्रिया है[2] इंजीनियरिंग डिजाइन प्रक्रिया में। यह सिस्टम इंजीनियरिंग और सॉफ्टवेयर इंजीनियरिंग में एक सामान्य भूमिका है।

"आवश्यकताएं इंजीनियरिंग" शब्द का पहला प्रयोग संभवतः 1964 में कॉन्फ़्रेंस पेपर मेंटेनेंस, मेंटेनेंसबिलिटी और सिस्टम रिक्वायरमेंट इंजीनियरिंग में हुआ था।[3] लेकिन यह 1990 के दशक के अंत तक आईईईई कंप्यूटर सोसाइटी ट्यूटोरियल के प्रकाशन के साथ सामान्य उपयोग में नहीं आया।[4] मार्च 1997 में और आवश्यकताओं इंजीनियरिंग पर एक सम्मेलन श्रृंखला की स्थापना जो अंतर्राष्ट्रीय आवश्यकता इंजीनियरिंग सम्मेलन में विकसित हुई है। 

जलप्रपात मॉडल  . में[5] आवश्यकताएँ इंजीनियरिंग को विकास प्रक्रिया के पहले चरण के रूप में प्रस्तुत किया जाता है। सॉफ्टवेयर के लिए  रैशनल यूनिफाइड प्रोसेस  (आरयूपी) सहित बाद के विकास के तरीके, यह मानते हैं कि आवश्यकता इंजीनियरिंग एक सिस्टम के जीवनकाल के दौरान जारी रहती है।

आवश्यकता प्रबंधन, जो सिस्टम इंजीनियरिंग प्रथाओं का एक उप-कार्य है, को इंटरनेशनल काउंसिल ऑन सिस्टम्स इंजीनियरिंग (INCOSE) मैनुअल में भी अनुक्रमित किया गया है।

गतिविधियां

विकसित की जा रही प्रणाली के प्रकार और संगठन के विशिष्ट अभ्यास (ओं) के आधार पर आवश्यकताओं की इंजीनियरिंग में शामिल गतिविधियां व्यापक रूप से भिन्न होती हैं[6] इनमें शामिल हो सकते हैं:

  1. आवश्यकताएँ प्रारंभ या आवश्यकताएँ - डेवलपर्स और हितधारक मिलते हैं; बाद वाले से सॉफ्टवेयर उत्पाद के संबंध में उनकी जरूरतों और चाहतों के बारे में पूछताछ की जाती है।
  2. आवश्यकताएँ विश्लेषण और बातचीत - आवश्यकताओं की पहचान की जाती है (यदि विकास पुनरावृत्त है तो नए सहित), और हितधारकों के साथ संघर्ष हल हो गए हैं। दोनों लिखित और ग्राफिकल उपकरण (बाद वाले आमतौर पर डिजाइन चरण में उपयोग किए जाते हैं, लेकिन कुछ उन्हें इस स्तर पर भी मददगार पाते हैं) सफलतापूर्वक सहायक के रूप में उपयोग किए जाते हैं। लिखित विश्लेषण टूल के उदाहरण: केस एस और उपयोगकर्ता कहानियां का उपयोग करें। ग्राफिकल टूल्स के उदाहरण: [[यूनिफाइड मॉडलिंग लैंग्वेज | यूएमएल][7] और एलएमएल ।
  3. सिस्टम मॉडलिंग - कुछ इंजीनियरिंग क्षेत्रों (या विशिष्ट स्थितियों) के लिए उत्पाद को इसके निर्माण या निर्माण शुरू होने से पहले पूरी तरह से डिजाइन और मॉडलिंग करने की आवश्यकता होती है। इसलिए, डिजाइन चरण अग्रिम में किया जाना चाहिए। उदाहरण के लिए, किसी भी अनुबंध को स्वीकृत और हस्ताक्षरित करने से पहले किसी भवन के ब्लूप्रिंट को विस्तृत किया जाना चाहिए। कई क्षेत्र जीवनचक्र मॉडलिंग भाषा के साथ सिस्टम के मॉडल प्राप्त कर सकते हैं, जबकि अन्य, यूएमएल का उपयोग कर सकते हैं। नोट: कई क्षेत्रों में, जैसे कि सॉफ्टवेयर इंजीनियरिंग, अधिकांश मॉडलिंग गतिविधियों को डिजाइन गतिविधियों के रूप में वर्गीकृत किया जाता है, न कि आवश्यकता इंजीनियरिंग गतिविधियों के रूप में।
  4. आवश्यकताएँ विनिर्देश - आवश्यकताएँ एक औपचारिक कलाकृति में प्रलेखित होती हैं जिसे आवश्यकताएँ विशिष्टता (RS) कहा जाता है, जो सत्यापन के बाद ही आधिकारिक हो जाएगी। यदि आवश्यक हो तो RS में लिखित और ग्राफिकल (मॉडल) दोनों तरह की जानकारी हो सकती है। उदाहरण: सॉफ़्टवेयर आवश्यकताएँ विनिर्देश (एसआरएस)।
  5. आवश्यकता सत्यापन - यह जांचना कि दस्तावेज की आवश्यकताएं और मॉडल सुसंगत हैं और हितधारक की जरूरतों को पूरा करते हैं। केवल अगर अंतिम मसौदा सत्यापन प्रक्रिया को पारित करता है, तो आरएस आधिकारिक हो जाता है।
  6. आवश्यकताएँ प्रबंधन - स्थापना के बाद से आवश्यकताओं से संबंधित सभी गतिविधियों का प्रबंधन, सिस्टम के विकसित होने पर पर्यवेक्षण करना, और यहां तक ​​कि इसके उपयोग में आने तक (जैसे, परिवर्तन, एक्सटेंशन, आदि)

इन्हें कभी-कभी कालानुक्रमिक चरणों के रूप में प्रस्तुत किया जाता है, हालांकि व्यवहार में, इन गतिविधियों में काफी अंतर होता है।

सॉफ्टवेयर परियोजना की सफलताओं में स्पष्ट रूप से योगदान करने के लिए आवश्यकताएँ इंजीनियरिंग को दिखाया गया है। [8]

समस्याएं

जर्मनी में एक सीमित अध्ययन ने इंजीनियरिंग आवश्यकताओं को लागू करने में संभावित समस्याएं प्रस्तुत कीं और उत्तरदाताओं से पूछा कि क्या वे सहमत हैं कि वे वास्तविक समस्याएं थीं। परिणामों को सामान्यीकरण के रूप में प्रस्तुत नहीं किया गया था, लेकिन यह सुझाव दिया गया था कि प्रमुख कथित समस्याएं अधूरी आवश्यकताएं, चलती लक्ष्य, और टाइम बॉक्सिंग थीं, कम समस्याएं संचार त्रुटियां, ट्रेसिबिलिटी की कमी, शब्दावली संबंधी समस्याएं और अस्पष्ट जिम्मेदारियां थीं।[9]

आलोचना

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

See also

References

  1. ↑ Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap (PDF). ICSE'00. Proceedings of the conference on the future of Software engineering. pp. 35–46. CiteSeerX 10.1.1.131.3116. doi:10.1145/336512.336523. ISBN 1-58113-253-0.
  2. ↑ Kotonya, Gerald; Sommerville, Ian (September 1998). Requirements Engineering: Processes and Techniques. John Wiley & Sons. ISBN 978-0-471-97208-2. Chemuturi, M. (2013). Requirements Engineering and Management for Software Development Projects. doi:10.1007/978-1-4614-5377-2. ISBN 978-1-4614-5376-5. S2CID 19818654.
  3. ↑ Dresner, K. H. Borchers (1964). Maintenance, maintainability, and system requirements engineering. SAE World Congress & Exhibition 1964. SAE Technical Paper 640591. doi:10.4271/640591.
  4. ↑ Thayer, Richard H.; Dorfman, Merlin, eds. (March 1997). Software Requirements Engineering (2nd ed.). IEEE Computer Society Press. ISBN 978-0-8186-7738-0.
  5. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems: Concepts and Techniques (PDF). ICSE'87. Proceedings of the 9th international conference on Software Engineering. pp. 1–9.
  6. ↑ Sommerville, Ian (2009). Software Engineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
  7. ↑ "Uncovering Requirements With UML Class Diagrams Part 1". tynerblain.com. March 7, 2008. Retrieved March 14, 2018.
  8. ↑ Hofmann, H.F.; Lehner, F. (2001). "Requirements engineering as a success factor in software projects". IEEE Software. 18 (4): 58–66. doi:10.1109/MS.2001.936219. ISSN 0740-7459.
  9. ↑ Méndez Fernández, Daniel; Wagner, Stefan (2015). "Naming the pain in requirements engineering: A design for a global family of surveys and first results from Germany". Information and Software Technology. 57: 616–643. arXiv:1611.04976. doi:10.1016/j.infsof.2014.05.008. S2CID 1924926.
  10. ↑ Ralph, Paul; Mohanani, Rahul (May 2015). "Is Requirements Engineering Inherently Counterproductive?". IEEE. doi:10.13140/2.1.3831.6321. {{cite journal}}: Cite journal requires |journal= (help)
  11. ↑ Ralph, P. (September 2013). "The illusion of requirements in software development". Requirements Engineering. 18 (3): 293–296. arXiv:1304.0116. Bibcode:2013arXiv1304.0116R. doi:10.1007/s00766-012-0161-4. S2CID 11499083.

External links

Retrieved from "https://alpha.indicwiki.in/index.php?title=आवश्यकताएं_इंजिनीयरिंग&oldid=29560"