कार्यात्मक आवश्यकता: Difference between revisions
No edit summary |
(text) |
||
| Line 6: | Line 6: | ||
आवश्यकता इंजीनियरिंग में जैसा परिभाषित किया गया है कि, कार्यात्मक आवश्यकताएं प्रणाली के विशेष परिणाम निर्दिष्ट करती हैं। यह गैर-कार्यात्मक आवश्यकताओं के विपरीत होना चाहिए, जो लागत और विश्वसनीयता इंजीनियरिंग जैसी समग्र विशेषताओं को निर्दिष्ट करते हैं। कार्यात्मक आवश्यकताएं प्रणाली के अनुप्रयोग संरचना को चलाती हैं, जबकि गैर-कार्यात्मक आवश्यकताएं प्रणाली के तकनीकी संरचना को चलाती हैं।<ref name="AdamsNon15" /> | आवश्यकता इंजीनियरिंग में जैसा परिभाषित किया गया है कि, कार्यात्मक आवश्यकताएं प्रणाली के विशेष परिणाम निर्दिष्ट करती हैं। यह गैर-कार्यात्मक आवश्यकताओं के विपरीत होना चाहिए, जो लागत और विश्वसनीयता इंजीनियरिंग जैसी समग्र विशेषताओं को निर्दिष्ट करते हैं। कार्यात्मक आवश्यकताएं प्रणाली के अनुप्रयोग संरचना को चलाती हैं, जबकि गैर-कार्यात्मक आवश्यकताएं प्रणाली के तकनीकी संरचना को चलाती हैं।<ref name="AdamsNon15" /> | ||
कुछ स्थितियों में आवश्यकता विश्लेषक कार्यात्मक आवश्यकताओं के सेट को इकट्ठा करने और मान्य करने के बाद स्थितियों का उपयोग करता है। कार्यात्मक आवश्यकताओं के संग्रह और परिवर्तन का पदानुक्रम, मोटे तौर पर बोलना है: उपयोगकर्ता / [[परियोजना हितधारक]] अनुरोध → विश्लेषण → केस का उपयोग करें → सम्मिलित करें। हितधारक अनुरोध करते हैं; प्रणाली इंजीनियर आवश्यकता के पहलुओं पर चर्चा, निरीक्षण और समझने का प्रयास करते हैं; उपयोग के मामले, इकाई संबंध आरेख, और अन्य मॉडल आवश्यकता को मान्य करने के लिए बनाए गए हैं; और, यदि प्रलेखित और अनुमोदित है, तो आवश्यकता को लागू/निगमित किया जाता है।<ref name="MITRESys14">{{cite book |url=https://www.mitre.org/publications/technical-papers/the-mitre-systems-engineering-guide |chapter=Requirements Engineering: Eliciting, Collecting, and Developing Requirements |title=MITER सिस्टम्स इंजीनियरिंग गाइड|author=MITRE Corporate Communications and Public Affairs |publisher=MITRE Corporation |pages=304–13 |isbn=9780615974422 |access-date=15 June 2018}}</ref> प्रत्येक उपयोग मामला एक या अधिक कार्यात्मक आवश्यकताओं के माध्यम से व्यवहारिक परिदृश्यों को दिखाता है। अधिकांशतः चूंकि, विश्लेषक उपयोग के स्थितियों के सेट को प्राप्त करके ''' | कुछ स्थितियों में आवश्यकता विश्लेषक कार्यात्मक आवश्यकताओं के सेट को इकट्ठा करने और मान्य करने के बाद स्थितियों का उपयोग करता है। कार्यात्मक आवश्यकताओं के संग्रह और परिवर्तन का पदानुक्रम, मोटे तौर पर बोलना है: उपयोगकर्ता / [[परियोजना हितधारक]] अनुरोध → विश्लेषण → केस का उपयोग करें → सम्मिलित करें। हितधारक अनुरोध करते हैं; प्रणाली इंजीनियर आवश्यकता के पहलुओं पर चर्चा, निरीक्षण और समझने का प्रयास करते हैं; उपयोग के मामले, इकाई संबंध आरेख, और अन्य मॉडल आवश्यकता को मान्य करने के लिए बनाए गए हैं; और, यदि प्रलेखित और अनुमोदित है, तो आवश्यकता को लागू/निगमित किया जाता है।<ref name="MITRESys14">{{cite book |url=https://www.mitre.org/publications/technical-papers/the-mitre-systems-engineering-guide |chapter=Requirements Engineering: Eliciting, Collecting, and Developing Requirements |title=MITER सिस्टम्स इंजीनियरिंग गाइड|author=MITRE Corporate Communications and Public Affairs |publisher=MITRE Corporation |pages=304–13 |isbn=9780615974422 |access-date=15 June 2018}}</ref> प्रत्येक उपयोग मामला एक या अधिक कार्यात्मक आवश्यकताओं के माध्यम से व्यवहारिक परिदृश्यों को दिखाता है। अधिकांशतः चूंकि, विश्लेषक उपयोग के स्थितियों के सेट को प्राप्त करके '''आरम्भ''' करेगा, जिससे विश्लेषक उन कार्यात्मक आवश्यकताओं को प्राप्त कर सकता है जिन्हें उपयोगकर्ता को प्रत्येक उपयोग के मामले को करने की अनुमति देने के लिए लागू किया जाना चाहिए। | ||
== प्रक्रिया == | == प्रक्रिया == | ||
विशिष्ट कार्यात्मक आवश्यकता में विशिष्ट नाम और संख्या, संक्षिप्त सारांश और औचित्य सम्मिलित होता है। इस जानकारी का उपयोग पाठक को यह समझने में ''' | विशिष्ट कार्यात्मक आवश्यकता में विशिष्ट नाम और संख्या, संक्षिप्त सारांश और औचित्य सम्मिलित होता है। इस जानकारी का उपयोग पाठक को यह समझने में '''सहयोग''' करने के लिए किया जाता है कि आवश्यकता की आवश्यकता क्यों है, और प्रणाली के विकास के माध्यम से आवश्यकता को ट्रैक करने के लिए होता है।<ref name="StellmanApplied05">{{cite book |url=https://books.google.com/books?id=IYdJocLVa8wC&pg=PA97 |chapter=Chapter 6: Software requirements|title=एप्लाइड सॉफ्टवेयर परियोजना प्रबंधन|first1=Andrew |last1=Stellman |first2=Jennifer |last2=Greene |publisher=O'Reilly Media |pages=97–130 |year=2005 |isbn=9780596553821 |access-date=15 June 2018}}</ref> आवश्यकता का सार आवश्यक व्यवहार का वर्णन है, जो स्पष्ट और पठनीय होना चाहिए। वर्णित व्यवहार संगठनात्मक या व्यावसायिक नियमों से आ सकता है, या इसे उपयोगकर्ताओं, हितधारकों और संगठन के अन्य विशेषज्ञों के साथ अभिज्ञान सत्रों के माध्यम से खोजा जा सकता है।<ref name="StellmanApplied05" />उपयोग के मामले के विकास के दौरान कई आवश्यकताओं को उजागर किया जा सकता है। जब ऐसा होता है, तो आवश्यकता विश्लेषक नाम और सारांश के साथ परोक्षी आवश्यकता बना सकते हैं, और विवरणों पर बाद में शोध कर सकते हैं, जिससे कि जब वे बेहतर ज्ञात हों तो उन्हें भरा जा सकता है। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 12:55, 10 May 2023
सॉफ्टवेयर इंजीनियरिंग और प्रणाली अभियांत्रिकी में, कार्यात्मक आवश्यकता प्रणाली या उसके घटक के फलन को परिभाषित करती है, जहां एक फलन को इनपुट और आउटपुट के बीच व्यवहार के विनिर्देश के रूप में वर्णित किया जाता है।[1]
कार्यात्मक आवश्यकताओं में गणना, तकनीकी विवरण, आंकड़ाप्रकलन और प्रसंस्करण, और अन्य विशिष्ट कार्यक्षमता सम्मिलित हो सकती है जो परिभाषित करती है कि प्रणाली को क्या पूरा करना है।[2] व्यवहार संबंधी आवश्यकताएं उन सभी स्थितियों का वर्णन करती हैं जहां प्रणाली कार्यात्मक आवश्यकताओं का उपयोग करता है, इन्हें उपयोग के स्थितियों में अधिकृत किया जाता है। कार्यात्मक आवश्यकताओं को गैर-कार्यात्मक आवश्यकताओं (जिसे गुणवत्ता आवश्यकताओं के रूप में भी जाना जाता है) द्वारा समर्थित किया जाता है, जो डिजाइन या कार्यान्वयन (जैसे प्रदर्शन आवश्यकताओं, सुरक्षा, या विश्वसनीयता) पर बाधाएं डालती हैं। सामान्यतः कार्यात्मक आवश्यकताओं को "प्रणाली को <आवश्यकता> करना चाहिए"के रूप में व्यक्त किया जाता है, जबकि गैर-कार्यात्मक आवश्यकताओं को " प्रणाली <आवश्यकता> होगा।"।[3] कार्यात्मक आवश्यकताओं को लागू करने की योजना प्रणाली डिज़ाइन में विस्तृत है, जबकि गैर-कार्यात्मक आवश्यकताओं को प्रणाली संरचना में विस्तृत किया गया है।[4][5]
आवश्यकता इंजीनियरिंग में जैसा परिभाषित किया गया है कि, कार्यात्मक आवश्यकताएं प्रणाली के विशेष परिणाम निर्दिष्ट करती हैं। यह गैर-कार्यात्मक आवश्यकताओं के विपरीत होना चाहिए, जो लागत और विश्वसनीयता इंजीनियरिंग जैसी समग्र विशेषताओं को निर्दिष्ट करते हैं। कार्यात्मक आवश्यकताएं प्रणाली के अनुप्रयोग संरचना को चलाती हैं, जबकि गैर-कार्यात्मक आवश्यकताएं प्रणाली के तकनीकी संरचना को चलाती हैं।[4]
कुछ स्थितियों में आवश्यकता विश्लेषक कार्यात्मक आवश्यकताओं के सेट को इकट्ठा करने और मान्य करने के बाद स्थितियों का उपयोग करता है। कार्यात्मक आवश्यकताओं के संग्रह और परिवर्तन का पदानुक्रम, मोटे तौर पर बोलना है: उपयोगकर्ता / परियोजना हितधारक अनुरोध → विश्लेषण → केस का उपयोग करें → सम्मिलित करें। हितधारक अनुरोध करते हैं; प्रणाली इंजीनियर आवश्यकता के पहलुओं पर चर्चा, निरीक्षण और समझने का प्रयास करते हैं; उपयोग के मामले, इकाई संबंध आरेख, और अन्य मॉडल आवश्यकता को मान्य करने के लिए बनाए गए हैं; और, यदि प्रलेखित और अनुमोदित है, तो आवश्यकता को लागू/निगमित किया जाता है।[6] प्रत्येक उपयोग मामला एक या अधिक कार्यात्मक आवश्यकताओं के माध्यम से व्यवहारिक परिदृश्यों को दिखाता है। अधिकांशतः चूंकि, विश्लेषक उपयोग के स्थितियों के सेट को प्राप्त करके आरम्भ करेगा, जिससे विश्लेषक उन कार्यात्मक आवश्यकताओं को प्राप्त कर सकता है जिन्हें उपयोगकर्ता को प्रत्येक उपयोग के मामले को करने की अनुमति देने के लिए लागू किया जाना चाहिए।
प्रक्रिया
विशिष्ट कार्यात्मक आवश्यकता में विशिष्ट नाम और संख्या, संक्षिप्त सारांश और औचित्य सम्मिलित होता है। इस जानकारी का उपयोग पाठक को यह समझने में सहयोग करने के लिए किया जाता है कि आवश्यकता की आवश्यकता क्यों है, और प्रणाली के विकास के माध्यम से आवश्यकता को ट्रैक करने के लिए होता है।[7] आवश्यकता का सार आवश्यक व्यवहार का वर्णन है, जो स्पष्ट और पठनीय होना चाहिए। वर्णित व्यवहार संगठनात्मक या व्यावसायिक नियमों से आ सकता है, या इसे उपयोगकर्ताओं, हितधारकों और संगठन के अन्य विशेषज्ञों के साथ अभिज्ञान सत्रों के माध्यम से खोजा जा सकता है।[7]उपयोग के मामले के विकास के दौरान कई आवश्यकताओं को उजागर किया जा सकता है। जब ऐसा होता है, तो आवश्यकता विश्लेषक नाम और सारांश के साथ परोक्षी आवश्यकता बना सकते हैं, और विवरणों पर बाद में शोध कर सकते हैं, जिससे कि जब वे बेहतर ज्ञात हों तो उन्हें भरा जा सकता है।
यह भी देखें
- फलन (कंप्यूटर विज्ञान)
- फंक्शन (इंजीनियरिंग)
- फलन (गणित)
- कार्यात्मक बिंदु
- कार्यात्मक अपघटन
- कार्यात्मक डिजाइन
- कार्यात्मक मॉडल
- चिंताओं का पृथक्करण
- सॉफ्टवेयर आकार
संदर्भ
- ↑ Fulton R, Vandermolen R (2017). "Chapter 4: Requirements - Writing Requirements". Airborne Electronic Hardware Design Assurance: A Practitioner's Guide to RTCA/DO-254. CRC Press. pp. 89–93. ISBN 9781351831420. Retrieved 15 June 2018.
- ↑ "Supplement 4-A, A Procedure for Requirements Analysis". सिस्टम इंजीनियरिंग बुनियादी बातों (PDF). United States Government US Army. 2001. ISBN 978-1484120835. Archived from the original (PDF) on 31 January 2017. Retrieved 18 March 2016.
- ↑ Loucopoulos, P. (2005). "Chapter 4: Requirements Engineering". In Clarkson J, Eckert C (eds.). Design Process Improvement: A Review of Current Practice. Springer-Verlag. pp. 116–139. ISBN 9781846280610.
- ↑ 4.0 4.1 Adams, K.M. (2015). "3.2 Definitions for Functional and Non-Functional Requirements". सिस्टम विश्लेषण और डिजाइन में गैर-कार्यात्मक आवश्यकताएं. Springer. pp. 45–50. ISBN 9783319183442.
- ↑ Jönsson P, Lindvall M (2006). "Chapter 6: Impact Analysis". In Aurum A, Wohlin C (eds.). इंजीनियरिंग और प्रबंध सॉफ्टवेयर आवश्यकताएँ. Springer Science & Business Media. pp. 117–42. ISBN 9783540282440.
- ↑ MITRE Corporate Communications and Public Affairs. "Requirements Engineering: Eliciting, Collecting, and Developing Requirements". MITER सिस्टम्स इंजीनियरिंग गाइड. MITRE Corporation. pp. 304–13. ISBN 9780615974422. Retrieved 15 June 2018.
- ↑ 7.0 7.1 Stellman, Andrew; Greene, Jennifer (2005). "Chapter 6: Software requirements". एप्लाइड सॉफ्टवेयर परियोजना प्रबंधन. O'Reilly Media. pp. 97–130. ISBN 9780596553821. Retrieved 15 June 2018.
