कार्यात्मक आवश्यकता: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Any task which a system must be able to complete}} सॉफ्टवेयर इंजीनियरिंग और [[प्रणाली अ...")
 
No edit summary
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Short description|Any task which a system must be able to complete}}
{{Short description|Any task which a system must be able to complete}}
[[सॉफ्टवेयर इंजीनियरिंग]] और [[[[प्रणाली]] अभियांत्रिकी]] में, एक कार्यात्मक आवश्यकता एक प्रणाली या उसके घटक के एक समारोह को परिभाषित करती है, जहां एक फ़ंक्शन को इनपुट और आउटपुट के बीच व्यवहार के विनिर्देश के रूप में वर्णित किया जाता है।<ref name="FultonAirborne17">{{cite book |url=https://books.google.com/books?id=ZQMvDwAAQBAJ&pg=PA89 |chapter=Chapter 4: Requirements - Writing Requirements |title=Airborne Electronic Hardware Design Assurance: A Practitioner's Guide to RTCA/DO-254 |vauthors=Fulton R, Vandermolen R |publisher=CRC Press |pages=89–93 |year=2017 |isbn=9781351831420 |access-date=15 June 2018}}</ref>
[[सॉफ्टवेयर इंजीनियरिंग]] और [[प्रणाली]] अभियांत्रिकी में, '''कार्यात्मक आवश्यकता''' प्रणाली या उसके घटक के फलन को परिभाषित करती है, जहां एक फलन को इनपुट और आउटपुट के बीच व्यवहार के विनिर्देश के रूप में वर्णित किया जाता है।<ref name="FultonAirborne17">{{cite book |url=https://books.google.com/books?id=ZQMvDwAAQBAJ&pg=PA89 |chapter=Chapter 4: Requirements - Writing Requirements |title=Airborne Electronic Hardware Design Assurance: A Practitioner's Guide to RTCA/DO-254 |vauthors=Fulton R, Vandermolen R |publisher=CRC Press |pages=89–93 |year=2017 |isbn=9781351831420 |access-date=15 June 2018}}</ref>
कार्यात्मक आवश्यकताओं में गणना, तकनीकी विवरण, डेटा हेरफेर और प्रसंस्करण, और अन्य विशिष्ट कार्यक्षमता शामिल हो सकती है जो परिभाषित करती है कि सिस्टम को क्या पूरा करना है।<ref>{{cite book |url=http://www.dau.mil/publications/publicationsDocs/SEFGuide%2001-01.pdf |title=सिस्टम इंजीनियरिंग बुनियादी बातों|chapter=Supplement 4-A, A Procedure for Requirements Analysis |publisher=United States Government US Army |year=2001 |ISBN=978-1484120835 |access-date=18 March 2016 |url-status=dead |archive-url=https://web.archive.org/web/20170131231503/http://www.dau.mil/publications/publicationsdocs/sefguide%2001-01.pdf |archive-date=31 January 2017 }}</ref> व्यवहार संबंधी आवश्यकताएं उन सभी मामलों का वर्णन करती हैं जहां सिस्टम कार्यात्मक आवश्यकताओं का उपयोग करता है, इन्हें उपयोग के मामलों में कैप्चर किया जाता है। कार्यात्मक आवश्यकताओं को [[गैर-कार्यात्मक आवश्यकता]]ओं (जिसे गुणवत्ता आवश्यकताओं के रूप में भी जाना जाता है) द्वारा समर्थित किया जाता है, जो डिजाइन या कार्यान्वयन (जैसे प्रदर्शन आवश्यकताओं, सुरक्षा, या विश्वसनीयता) पर बाधाएं डालती हैं। आम तौर पर, कार्यात्मक आवश्यकताओं को फॉर्म में व्यक्त किया जाता है सिस्टम को <आवश्यकता> करना चाहिए, जबकि गैर-कार्यात्मक आवश्यकताएं फॉर्म सिस्टम लेती हैं <आवश्यकता> होगी।<ref name="LoucopoulosRequire05">{{cite book |chapter=Chapter 4: Requirements Engineering |title=Design Process Improvement: A Review of Current Practice |author=Loucopoulos, P. |veditors=Clarkson J, Eckert C |publisher=Springer-Verlag |pages=116–139 |year=2005 |isbn=9781846280610}}</ref> कार्यात्मक आवश्यकताओं को लागू करने की योजना सिस्टम डिज़ाइन में विस्तृत है, जबकि गैर-कार्यात्मक आवश्यकताओं को [[सिस्टम आर्किटेक्चर]] में विस्तृत किया गया है।<ref name="AdamsNon15">{{cite book |chapter=3.2 Definitions for Functional and Non-Functional Requirements |title=सिस्टम विश्लेषण और डिजाइन में गैर-कार्यात्मक आवश्यकताएं|author=Adams, K.M. |publisher=Springer |pages=45–50 |year=2015 |isbn=9783319183442}}</ref><ref name="JönssonImpact06">{{cite book |chapter=Chapter 6: Impact Analysis |title=इंजीनियरिंग और प्रबंध सॉफ्टवेयर आवश्यकताएँ|vauthors=Jönsson P, Lindvall M |veditors=Aurum A, Wohlin C |publisher=Springer Science & Business Media |pages=117–42 |year=2006 |isbn=9783540282440}}</ref>


जैसा कि आवश्यकता इंजीनियरिंग में परिभाषित किया गया है, कार्यात्मक आवश्यकताएं सिस्टम के विशेष परिणाम निर्दिष्ट करती हैं। यह गैर-कार्यात्मक आवश्यकताओं के विपरीत होना चाहिए, जो लागत और विश्वसनीयता इंजीनियरिंग जैसी समग्र विशेषताओं को निर्दिष्ट करते हैं। कार्यात्मक आवश्यकताएं सिस्टम के एप्लिकेशन आर्किटेक्चर को चलाती हैं, जबकि गैर-कार्यात्मक आवश्यकताएं सिस्टम के तकनीकी आर्किटेक्चर को चलाती हैं।<ref name="AdamsNon15" />
कार्यात्मक आवश्यकताओं में गणना, तकनीकी विवरण, आंकड़ाप्रकलन और प्रसंस्करण, और अन्य विशिष्ट कार्यक्षमता सम्मिलित हो सकती है जो परिभाषित करती है कि प्रणाली को क्या पूरा करना है।<ref>{{cite book |url=http://www.dau.mil/publications/publicationsDocs/SEFGuide%2001-01.pdf |title=सिस्टम इंजीनियरिंग बुनियादी बातों|chapter=Supplement 4-A, A Procedure for Requirements Analysis |publisher=United States Government US Army |year=2001 |ISBN=978-1484120835 |access-date=18 March 2016 |url-status=dead |archive-url=https://web.archive.org/web/20170131231503/http://www.dau.mil/publications/publicationsdocs/sefguide%2001-01.pdf |archive-date=31 January 2017 }}</ref> व्यवहार संबंधी आवश्यकताएं उन सभी स्थितियों का वर्णन करती हैं जहां प्रणाली कार्यात्मक आवश्यकताओं का उपयोग करता है, इन्हें उपयोग के स्थितियों में अधिकृत किया जाता है। कार्यात्मक आवश्यकताओं को [[गैर-कार्यात्मक आवश्यकता]]ओं (जिसे गुणवत्ता आवश्यकताओं के रूप में भी जाना जाता है) द्वारा समर्थित किया जाता है, जो डिजाइन या कार्यान्वयन (जैसे प्रदर्शन आवश्यकताओं, सुरक्षा, या विश्वसनीयता) पर बाधाएं डालती हैं। सामान्यतः कार्यात्मक आवश्यकताओं को "प्रणाली को <आवश्यकता> करना चाहिए"के रूप में व्यक्त किया जाता है, जबकि गैर-कार्यात्मक आवश्यकताओं को " प्रणाली <आवश्यकता> होगा।"।<ref name="LoucopoulosRequire05">{{cite book |chapter=Chapter 4: Requirements Engineering |title=Design Process Improvement: A Review of Current Practice |author=Loucopoulos, P. |veditors=Clarkson J, Eckert C |publisher=Springer-Verlag |pages=116–139 |year=2005 |isbn=9781846280610}}</ref> कार्यात्मक आवश्यकताओं को लागू करने की योजना प्रणाली डिज़ाइन में विस्तृत है, जबकि गैर-कार्यात्मक आवश्यकताओं को [[सिस्टम आर्किटेक्चर|प्रणाली संरचना]] में विस्तृत किया गया है।<ref name="AdamsNon15">{{cite book |chapter=3.2 Definitions for Functional and Non-Functional Requirements |title=सिस्टम विश्लेषण और डिजाइन में गैर-कार्यात्मक आवश्यकताएं|author=Adams, K.M. |publisher=Springer |pages=45–50 |year=2015 |isbn=9783319183442}}</ref><ref name="JönssonImpact06">{{cite book |chapter=Chapter 6: Impact Analysis |title=इंजीनियरिंग और प्रबंध सॉफ्टवेयर आवश्यकताएँ|vauthors=Jönsson P, Lindvall M |veditors=Aurum A, Wohlin C |publisher=Springer Science & Business Media |pages=117–42 |year=2006 |isbn=9783540282440}}</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="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="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" />उपयोग के मामले के विकास के दौरान कई आवश्यकताओं को उजागर किया जा सकता है। जब ऐसा होता है, तो आवश्यकता विश्लेषक एक नाम और सारांश के साथ एक प्लेसहोल्डर आवश्यकता बना सकते हैं, और विवरणों पर बाद में शोध कर सकते हैं, ताकि जब वे बेहतर ज्ञात हों तो उन्हें भरा जा सके।
विशिष्ट कार्यात्मक आवश्यकता में विशिष्ट नाम और संख्या, संक्षिप्त सारांश और औचित्य सम्मिलित होता है। इस जानकारी का उपयोग पाठक को यह समझने में सहयोग करने के लिए किया जाता है कि आवश्यकता की आवश्यकता क्यों है, और प्रणाली के विकास के माध्यम से आवश्यकता को ट्रैक करने के लिए होता है।<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" />उपयोग के मामले के विकास के दौरान कई आवश्यकताओं को उजागर किया जा सकता है। जब ऐसा होता है, तो आवश्यकता विश्लेषक नाम और सारांश के साथ परोक्षी आवश्यकता बना सकते हैं, और विवरणों पर बाद में शोध कर सकते हैं, जिससे कि जब वे बेहतर ज्ञात हों तो उन्हें भरा जा सकता है।


== यह भी देखें ==
== यह भी देखें ==


* [[समारोह (कंप्यूटर विज्ञान)]]
* [[समारोह (कंप्यूटर विज्ञान)|फलन (कंप्यूटर विज्ञान)]]
* फंक्शन (इंजीनियरिंग)
* फंक्शन (इंजीनियरिंग)
* [[समारोह (गणित)]]
* [[समारोह (गणित)|फलन (गणित)]]
* कार्यात्मक बिंदु
* कार्यात्मक बिंदु
* [[कार्यात्मक अपघटन]]
* [[कार्यात्मक अपघटन]]
* [[कार्यात्मक डिजाइन]]
* [[कार्यात्मक डिजाइन]]
* [[कार्यात्मक मॉडल]]
* [[कार्यात्मक मॉडल]]
* [[चिंताओ का विभाजन]]
* [[चिंताओ का विभाजन|चिंताओं का पृथक्करण]]
* [[सॉफ्टवेयर आकार]]
* [[सॉफ्टवेयर आकार]]


==संदर्भ==
==संदर्भ==
{{reflist}}
{{reflist}}
[[Category: सॉफ़्टवेयर आवश्यकताएं]] [[Category: प्रणाली अभियांत्रिकी]]


[[Category: Machine Translated Page]]
[[Category:Created On 26/04/2023]]
[[Category:Created On 26/04/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:प्रणाली अभियांत्रिकी]]
[[Category:सॉफ़्टवेयर आवश्यकताएं]]

Latest revision as of 09:46, 18 May 2023

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

कार्यात्मक आवश्यकताओं में गणना, तकनीकी विवरण, आंकड़ाप्रकलन और प्रसंस्करण, और अन्य विशिष्ट कार्यक्षमता सम्मिलित हो सकती है जो परिभाषित करती है कि प्रणाली को क्या पूरा करना है।[2] व्यवहार संबंधी आवश्यकताएं उन सभी स्थितियों का वर्णन करती हैं जहां प्रणाली कार्यात्मक आवश्यकताओं का उपयोग करता है, इन्हें उपयोग के स्थितियों में अधिकृत किया जाता है। कार्यात्मक आवश्यकताओं को गैर-कार्यात्मक आवश्यकताओं (जिसे गुणवत्ता आवश्यकताओं के रूप में भी जाना जाता है) द्वारा समर्थित किया जाता है, जो डिजाइन या कार्यान्वयन (जैसे प्रदर्शन आवश्यकताओं, सुरक्षा, या विश्वसनीयता) पर बाधाएं डालती हैं। सामान्यतः कार्यात्मक आवश्यकताओं को "प्रणाली को <आवश्यकता> करना चाहिए"के रूप में व्यक्त किया जाता है, जबकि गैर-कार्यात्मक आवश्यकताओं को " प्रणाली <आवश्यकता> होगा।"।[3] कार्यात्मक आवश्यकताओं को लागू करने की योजना प्रणाली डिज़ाइन में विस्तृत है, जबकि गैर-कार्यात्मक आवश्यकताओं को प्रणाली संरचना में विस्तृत किया गया है।[4][5]

आवश्यकता इंजीनियरिंग में जैसा परिभाषित किया गया है कि, कार्यात्मक आवश्यकताएं प्रणाली के विशेष परिणाम निर्दिष्ट करती हैं। यह गैर-कार्यात्मक आवश्यकताओं के विपरीत होना चाहिए, जो लागत और विश्वसनीयता इंजीनियरिंग जैसी समग्र विशेषताओं को निर्दिष्ट करते हैं। कार्यात्मक आवश्यकताएं प्रणाली के अनुप्रयोग संरचना को चलाती हैं, जबकि गैर-कार्यात्मक आवश्यकताएं प्रणाली के तकनीकी संरचना को चलाती हैं।[4]

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

प्रक्रिया

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

यह भी देखें

संदर्भ

  1. ↑ 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.
  2. ↑ "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.
  3. ↑ 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. ↑ 4.0 4.1 Adams, K.M. (2015). "3.2 Definitions for Functional and Non-Functional Requirements". सिस्टम विश्लेषण और डिजाइन में गैर-कार्यात्मक आवश्यकताएं. Springer. pp. 45–50. ISBN 9783319183442.
  5. ↑ 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.
  6. ↑ 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. ↑ 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.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=कार्यात्मक_आवश्यकता&oldid=162472’