कार्यात्मक आवश्यकता: Difference between revisions
(Created page with "{{Short description|Any task which a system must be able to complete}} सॉफ्टवेयर इंजीनियरिंग और [[प्रणाली अ...") |
No edit summary |
||
| Line 4: | Line 4: | ||
जैसा कि आवश्यकता इंजीनियरिंग में परिभाषित किया गया है, कार्यात्मक आवश्यकताएं सिस्टम के विशेष परिणाम निर्दिष्ट करती हैं। यह गैर-कार्यात्मक आवश्यकताओं के विपरीत होना चाहिए, जो लागत और विश्वसनीयता इंजीनियरिंग जैसी समग्र विशेषताओं को निर्दिष्ट करते हैं। कार्यात्मक आवश्यकताएं सिस्टम के एप्लिकेशन आर्किटेक्चर को चलाती हैं, जबकि गैर-कार्यात्मक आवश्यकताएं सिस्टम के तकनीकी आर्किटेक्चर को चलाती हैं।<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> प्रत्येक उपयोग मामला व्यवहार परिदृश्यों को एक या अधिक कार्यात्मक आवश्यकताओं के माध्यम से दिखाता है। अक्सर, हालांकि, एक विश्लेषक उपयोग के मामलों के एक सेट को प्राप्त करके शुरू करेगा, जिससे विश्लेषक उन कार्यात्मक आवश्यकताओं को प्राप्त कर सकता है जिन्हें उपयोगकर्ता को प्रत्येक उपयोग के मामले को करने की अनुमति देने के लिए लागू किया जाना चाहिए। | |||
== प्रक्रिया == | == प्रक्रिया == | ||
Revision as of 12:47, 3 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.
