UML उपयोग केस संबंधों को समझना: «include» और «extend» की शक्ति और खतरा

सॉफ्टवेयर आवश्यकताओं और सिस्टम मॉडलिंग की दुनिया में, UML (एकीकृत मॉडलिंग भाषा) सिस्टम व्यवहार को दृश्य रूप से दर्शाने के लिए एक मूल बिंदु बना हुआ है। इसकी सबसे शक्तिशाली लेकिन बार-बार गलत समझी जाने वाली विशेषताओं में से उपयोग केसों के बीच के «include» और  «extend»  उपयोग केसों के बीच संबंध हैं। इन तकनीकों का उद्देश्य है प्रतिलिपि को कम करना, परिवर्तनशीलता का प्रबंधन करना, और मॉड्यूलरता को बढ़ावा देना उपयोग केस मॉडल में। हालांकि, उनके गलत उपयोग का दायरा बहुत व्यापक है—जिसके कारण अत्यधिक जटिल आरेख, स्टेकहोल्डर्स में भ्रम और उपयोगकर्ता मूल्य पर ध्यान केंद्रित करने की क्षमता का नुकसान होता है।

 

 

यह लेख एक व्यापक, व्यावहारिक और विशेषज्ञों द्वारा समर्थित मार्गदर्शिका «include» और «extend» के सामान्य त्रुटियों को समझने, लागू करने और बचने के लिए। हम उनके वास्तविक अर्थ, उन्हें एक साथ तुलना करें, यह जांचें कि वे DFDs (कार्यात्मक विभाजन) के उसी जाल में क्यों फंस जाते हैं, और प्रदान करें आधुनिक उत्तम व्यवहार 2025–2026 की टीमों के लिए—विशेष रूप से एजाइल, लीन या हाइब्रिड वातावरण में काम करने वाली टीमों के लिए।

---

🔹 मूल अर्थ: «include» और «extend» का वास्तविक अर्थ वास्तव में क्या है

✅ «include»: अनिवार्य पुनर्उपयोग – “हमेशा आवश्यक” उप-प्रवाह

परिभाषा:
«include» संबंध एक का निरूपण करता हैअनिवार्य, हमेशा निष्पादित उप-प्रवाह जो बहुत से उपयोग केसों में पुनर्उपयोग के लिए निकाला गया है।

📌 मुख्य विशेषताएँ:

• हमेशा निष्पादित: शामिल उपयोग केस के प्रत्येक बार आधार उपयोग केस के आह्वान के साथ चलता है।

• इसके बिना आधार उपयोग केस अधूरा है: शामिल व्यवहार के बिना, आधार उपयोग केस अपने उद्देश्य को पूरा नहीं कर सकता है।

• निर्भरता दिशा: तीर का निर्देश हैआधार → शामिल.

• अलग-अलग अर्थ: शामिल उपयोग केस आमतौर परअकेले अर्थपूर्ण नहीं होता है—यह केवल एक बड़े प्रक्रिया के हिस्से के रूप में ही समझ में आता है।

• अनुमान: जैसे एकफ़ंक्शन कॉलयाउप-कार्य प्रोग्रामिंग में—मुख्य रूटीन के लिए आवश्यक।

🧠 पारंपरिक स्मृति याददाश्त:

“करने के लिएलॉगिन, आपको आवश्यकता हैउपयोगकर्ता की प्रमाणीकरण.”
“करने के लिएनकद निकासी, आपको आवश्यकता है पिन की पुष्टि करें.”

ये हैं अनिवार्य चरण. आप प्रमाणीकरण के बिना लॉग इन नहीं कर सकते। आप पिन की पुष्टि किए बिना नकद निकासी नहीं कर सकते।

💡 उपयोग कब करें:

• जब एक सामान्य, जटिल, पुनर्उपयोगी व्यवहार में दिखाई देता है दो या अधिक उपयोग केस।

• उदाहरण:

  • उपयोगकर्ता की प्रमाणित करें

  • लॉग ऑडिट ट्रेल

  • सूचना भेजें

  • इनपुट प्रारूप की पुष्टि करें

✅ नियम ऑफ थम्ब: «include» का उपयोग केवल तभी करें जब पुनर्उपयोग किया गया व्यवहार है महत्वपूर्ण, गैर-महत्वपूर्ण, और दिखाई देता है ≥2–3 उपयोग केस।

---

✅ «extend»: वैकल्पिक विकल्प – “शर्ताधीन एड-ऑन”

परिभाषा:
«extend» संबंध परिभाषित करता हैवैकल्पिक, शर्तपूर्ण, या विकल्पीयव्यवहार जोकिसी विशिष्ट में लगाया जाता हैएक विशिष्टएक्सटेंशन बिंदुमूल उपयोग केस के।

📌 मुख्य विशेषताएँ:

• शर्तपूर्ण रूप से निष्पादित: केवल कुछ निश्चित परिस्थितियों में चलता है।

• मूल उपयोग केस अकेले पूरा होता है: सामान्य प्रवाह एक्सटेंशन के बिना काम करता है।

• निर्भरता दिशा: तीर की दिशा हैएक्सटेंडिंग → मूल (पीछे की ओर)।

• अलग से अर्थ: एक्सटेंडिंग उपयोग केस हैलगभग कभी भी अकेले सार्थक नहीं होता है—यह केवल संदर्भ में ही सार्थक होता हैसंदर्भ में.

• अनुमान: जैसे एकहुक, प्लगइन, याAOP (पहलू-आधारित प्रोग्रामिंग) सलाह—यह एक परिभाषित बिंदु पर व्यवहार जोड़ता है।

🧠 पारंपरिक स्मृति सहायता:

“जब कर रहे हो उड़ान बुक करें, आप शायद चाहेंगे कि पसंदीदा सीट चुनें.”
“जब कर रहे हो क्रेडिट कार्ड से भुगतान करें, आप शायद करना होगा 3D सुरक्षा कोड दर्ज करें.”

ये हैं वैकल्पिक सुधार—मूल प्रवाह के लिए आवश्यक नहीं है।

💡 उपयोग कब करें:

• मॉडल करने के लिए वैकल्पिक मार्ग, अपवाद, या वैकल्पिक विशेषताएं.

• जब उपयोग केस में है विभिन्न व्यवहार शर्तों पर आधारित (उदाहरण के लिए, उपयोगकर्ता के भूमिकाएं, सिस्टम की स्थिति, पसंदीदा बातें)।

• उदाहरण:

  • छूट लागू करें (विस्तारित करें आदेश दें)

  • लौटाए जाने का अनुरोध करें (विस्तारित करें भुगतान प्रक्रिया)

  • PDF रसीद उत्पन्न करें (विस्तारित करें लेनदेन पूरा करें)

✅ नियम ऑफ थम्ब: «विस्तारित करें» का संकोचित उपयोग करें—केवल महत्वपूर्ण अंतर स्पष्ट विस्तार बिंदु.

---

🔍 त्वरित तुलना: «शामिल करें» बनाम «विस्तारित करें»

पहलू	«शामिल करें»	«विस्तारित करें»
क्रियान्वयन	हमेशा	कभी-कभी / शर्त के आधार पर
आधार UC अकेले पूरा होता है?	❌ नहीं — शामिल पर निर्भर है	✅ हां — विस्तार के बिना पूरा
निर्भरता दिशा	आधार → शामिल	विस्तार → आधार
तीर की दिशा	शामिल उपयोग केस की ओर इशारा करता है	आधार उपयोग केस की ओर इशारा करता है
मुख्य लक्ष्य	अनिवार्य, साझा चरणों का पुनर्उपयोग	वैकल्पिक/विकल्पीय प्रवाहों का प्रबंधन
अनुमान	फ़ंक्शन कॉल / उपकार्य	हुक / प्लगइन / AOP सलाह
अलग-थलग अर्थ?	हल्के अंश में	लगभग कभी नहीं
सबसे अच्छा उपयोग	पुनर्उपयोग योग्य, जटिल, क्रॉस-कटिंग चिंताएं	शर्ती, वैकल्पिक या वैकल्पिक व्यवहार

---

⚠️ “विघटन भूल” : उपयोग केस आरेख क्यों गलत दिशा में जाते हैं

बिल्कुल वैसे ही जैसेDFD (डेटा प्रवाह आरेख)के दुखी होते हैंकार्यात्मक विघटन भूल, उपयोग केस आरेख भी हैंएक ही महामारी के शिकार: अत्यधिक विघटन.

📉 DFD कार्यात्मक विघटन भूल (सारांश):

• टीमें प्रक्रियाओं को छोटे-छोटे बुलबुलों में बांटती रहती हैं।

• चित्र दसों छोटे, कम स्तरीय कार्यों में फूट जाते हैं।

• द मूल उद्देश्य—उपयोगकर्ता को मूल्य प्रदान करना—खो जाता है।

• अंततः ऐसा लगता है कि प्रायोगिक कोड या आंतरिक एल्गोरिदम डिज़ाइनउपयोगकर्ता के व्यवहार के बजाय।

🧨 उपयोग केस “कार्यात्मक विघटन रोग”:

• हर छोटा चरण अपने अलग उपयोग केस बन जाता है:

  • उपयोगकर्ता नाम दर्ज करें

  • पासवर्ड दर्ज करें

  • लॉगिन बटन पर क्लिक करें

  • फॉर्मेट की पुष्टि करें

  • त्रुटि संदेश प्रदर्शित करें

• «शामिल करें» का उपयोग आलसी ढंग से हर क्रिया को विभाजित करने के लिए।

• परिणाम: एक गहन पदानुक्रम उपयोग केस का (A → B → C → D…) जिसमें कोई स्पष्ट कार्यकर्ता लक्ष्य नहीं है।

• चित्र बन जाते हैं रखरखाव असंभव, भ्रमित करने वाला, और बेकार हितधारकों के लिए।

❌ लाल झंडा: यदि आपके उपयोग केस आरेख में है 15–20 उपयोग केस से अधिक, या यदि अधिकांश मूल उपयोग केस 2–4 चरणों के हैं, आप शायद फंदे में हैं।

---

🛠️ इसके कारण क्या होते हैं: सामान्य त्रुटियाँ और गलत धारणाएँ

त्रुटि	व्याख्या	बचने का तरीका
«include» का अत्यधिक उपयोग करना	प्रत्येक उप-चरण को पुनर्उपयोगी उपयोग केस के रूप में मानना।	केवल «include» का उपयोग करें महत्वपूर्ण, पुनर्उपयोगी, क्रॉस-कटिंग व्यवहार (उदाहरण के लिए, प्रमाणीकरण, लॉगिंग)।
तीर की दिशा में भ्रम	«include» तीर को पीछे (मूल ← शामिल) या «extend» तीर को आगे बनाना।	याद रखें: include = मूल → शामिल; extend = विस्तारित → मूल.
विकल्पों के लिए «extend» का उपयोग करना	विकल्पीय प्रवाह का मॉडलिंग अंदर एक उपयोग केस को «extend» के रूप में बनाना, बजाय टेक्स्टुअल विकल्पों के उपयोग के।	उपयोग करें पाठ्य वैकल्पिक प्रवाह अधिकांश विकल्पों के लिए। «एक्सटेंड» का उपयोग केवल वास्तविक वैकल्पिक विस्तार.
शामिल करने के श्रृंखला बनाना	A → B → C → D → E…	गहन श्रृंखलाओं से बचें। यदि आपको बहुत सारे शामिल करने की आवश्यकता है, तो विचार करें एकल दोहराए जा सकने वाले उपयोग केस में पुनर्गठित करना.
अस्पष्ट विस्तार बिंदु	स्पष्ट, नामांकित सम्मिलन बिंदु के बिना «एक्सटेंड» संबंध जोड़ना।	परिभाषित करें स्पष्ट विस्तार बिंदु (उदाहरण के लिए, “भुगतान पुष्टि के बाद”) मूल उपयोग केस में।
आरेख अव्यवस्था	बहुत सारे उपयोग केस और संबंध → दृश्य शोर।	आरेखों को रखें छोटे, एकांतरित और अभिनेता-केंद्रित। प्रत्येक उपप्रणाली के लिए बहुत सारे आरेखों का उपयोग करें।
हितधारकों में भ्रम	तकनीकी रूप से अप्रतिभागी हितधारकों को «शामिल/विस्तार» समझने में कठिनाई होती है।	उपयोग करें पाठ्य परिदृश्य या उपयोगकर्ता कथा नक्शे स्पष्टता के लिए।
डिज़ाइन स्तर का मॉडलिंग	उपयोगकर्ता लक्ष्यों के बजाय आंतरिक संरचना का मॉडलिंग (उदाहरण के लिए, “डेटाबेस कॉल”)।	केंद्रित रहें एक्टर मूल्य—कार्यान्वयन नहीं।
अंतहीन विवाद	दल दृश्यों लिखने के बजाय “क्या इसे शामिल करना चाहिए या विस्तार करना चाहिए?” पर बहस कर रहे हैं।	उपयोग करें व्यावहारिक बुद्धिमत्ता और औपचारिकता की तुलना में स्पष्टता को प्राथमिकता दें.

---

✅ 2025–2026 के लिए सर्वोत्तम अभ्यास: आधुनिक, एजाइल दृष्टिकोण

आवश्यकता इंजीनियरिंग का दृश्य बदल गया है। एजाइल, लीन और उत्पाद-नेतृत्व वाली टीमें भारी UML आरेखों से दूर बढ़ रही हैं, इसके बजाय हल्के, मूल्य-केंद्रित तकनीकें।

🎯 मूल सिद्धांत: एक्टर मूल्य पर ध्यान केंद्रित करें, आंतरिक संरचना नहीं

❗ किसी «शामिल» या «विस्तार» को जोड़ने से पहले यह प्रश्न पूछें:
“क्या यह संबंध उपयोगकर्ता को लक्ष्य को समझने में मदद करता है, या यह सिर्फ सिस्टम को बांट रहा है?”

✅ सिफारिश किए गए आधुनिक अभ्यास:

1. «शामिल» का संक्षिप्त उपयोग करें — केवल मुख्य पुनर्उपयोगी व्यवहार के लिए

• केवल क्रॉस-कटिंग चिंताएं जो बहुल उपयोग केस में।

• उदाहरण:

  • उपयोगकर्ता की प्रमाणित करें

  • ईमेल अधिसूचना भेजें

  • सुरक्षा घटना लॉग करें

  • व्यापार नियम लागू करें

❌ बचें: उपयोगकर्ता नाम दर्ज करें, सबमिट पर क्लिक करें, ईमेल प्रारूप की पुष्टि करें

2. «extend» के बजाय पाठ्य वैकल्पिक प्रवाहों को प्राथमिकता दें

• बजाय इसके:

  «extend»: पसंदीदा सीट चुनें → उड़ान बुक करें
  

• उपयोग करें:

  उपयोग केस: उड़ान बुक करें
  ...
  वैकल्पिक प्रवाह:
    1. उपयोगकर्ता "पसंदीदा सीट" विकल्प चुनता है।
    2. सिस्टम सीट मानचित्र प्रदर्शित करता है।
    3. उपयोगकर्ता सीट चुनता है।
    4. सिस्टम सीट प्राथमिकता लागू करता है।
  

✅ क्यों? पाठ्य प्रवाह हैं पढ़ने में आसान, अधिक लचीले, और गलत उपयोग के कम झंझट.

3. रखें उपयोग केस आरेखछोटे और एकाग्र

• प्रत्येक के लिए एक आरेख किरदार या उपप्रणाली.

• केवल सीमित 5–10 उपयोग केस प्रति आरेख।

• उपयोग करें पैकेज आरेख या संदर्भ आरेख उच्च स्तरीय संरचना दिखाने के लिए।

4. पूछें: “क्या एक उपयोगकर्ता कहानी मानचित्र इसे बेहतर तरीके से संचारित करेगा?”

• यदि आप 10+ «शामिल करें»/«विस्तारित» संबंधों का उपयोग कर रहे हैं, तो आरेख को बदलने के बारे में सोचें:

  • एक उपयोगकर्ता कहानी मानचित्र

  • एक परिदृश्य-आधारित तालिका

  • एक सरल प्रवाहचित्र मुख्य मार्गों के साथ

🔄 आधुनिक प्रवृत्ति: कई एजाइल टीमें कुल मिलाकर उपयोग केस आरेखों से बचती हैं या उनका उपयोग करें केवल उच्च स्तरीय खोज के लिए.

5. अर्थपूर्ण विकल्पों के लिए केवल «extend» का उपयोग करें

• «extend» का उपयोग केवल वैकल्पिक, गैर-मुख्य विशेषताएँ जो:

  • हैं दुर्लभ रूप से उपयोग किए जाते हैं

  • हैं संदर्भ-निर्भर

  • हैं स्वतंत्र मुख्य लक्ष्य से

✅ उदाहरण:
भुगतान प्रक्रिया (आधार)
3D सुरक्षा प्रमाणीकरण लागू करें (विस्तार) — केवल तभी जब बैंक द्वारा आवश्यक हो

❌ बचें:
कार्ड संख्या दर्ज करें → कार्ड की प्रमाणित करें → भुगतान प्रक्रिया (सभी एक ही उपयोग केस के चरण होने चाहिए)

---

📊 सारांश: «include» और «extend» के स्वर्ण नियम

नियम	मार्गदर्शिका
1. «include» = अनिवार्य	केवल के लिए उपयोग करेंमौलिक, पुनर्उपयोगी चरण जो ≥2 उपयोग केस में दिखाई देते हैं।
2. «extend» = वैकल्पिक	केवल निम्नलिखित के लिए उपयोग करेंशर्ती, विकल्पीय, या दुर्लभव्यवहार।
3. आधार उपयोग केस पूर्ण होना चाहिए	«extend»: आधार अकेले काम करता है। «include»: इसके बिना आधार अपूर्ण है।
4. इसे सरल रखें	यदि उपयोग केस में «include»/«extend» के बाद <4–6 चरण हैं, तो आपने अतिरिक्त विभाजन कर दिया है।
5. पठनीयता को प्राथमिकता दें	पाठ्य स्थितियाँ > जटिल आरेख।
6. श्रृंखलाओं से बचें	कोई A → B → C → D नहीं। इसे एक उपयोगी उपयोग केस में पुनर्गठित करें।
7. अपने दर्शकों को जानें	हितधारकों को «include» तीरों के बारे में परवाह नहीं है—वे मूल्य के बारे में चिंतित हैं.
8. पूछें: “क्या यह उपयोगकर्ता लक्ष्य है या आंतरिक चरण है?”	यदि यह कार्यकर्ता के लिए लक्ष्य नहीं है, तो यह शायद उपयोग केस में नहीं फिट होगा।

---

🎯 अंतिम विचार: उपकरण, फंदे नहीं

«include» और «extend» हैंशक्तिशाली उपकरण—कठोर नियम नहीं। उनका डिज़ाइन इस उद्देश्य के लिए किया गया था:

• प्रतिलिपि को कम करें

• परिवर्तनशीलता का प्रबंधन करें

• रखरखाव में सुधार करें

लेकिन जैसेDFD में कार्यात्मक विभाजनवे बन जाते हैंखतरनाक हथियारजब अधिक उपयोग किया जाता है। वास्तविक खतरा संबंधों के खुद में नहीं है—यह हैउपयोगकर्ता के लक्ष्य को देखने से वंचित होना.

🔥 याद रखें:
एक उपयोग केस एक तकनीकी प्रक्रिया नहीं है।
यह एक है उपयोगकर्ता द्वारा प्राप्त किए जाने वाले लक्ष्य के बारे में कहानी—और यह कि सिस्टम कैसे मदद करता है।

संदेह होने पर, खुद से पूछें:

“क्या उपयोगकर्ता इसे UML जाने बिना समझ पाएगा?”
अगर नहीं, तो सरल बनाएं।
अगर हां, तो आप सही रास्ते पर हैं।

---

📚 अधिक पठन और संदर्भ

• UML विनिर्माण (OMG): www.omg.org/spec/UML

• मार्टिन फाउलर – उपयोग केस मॉडलिंग: विश्लेषण पैटर्न & UML छानी हुई

• इवर जैकोबसन – ऑब्जेक्ट लाभ: उपयोग केस पर आधारभूत कार्य

• एजाइल मॉडलिंग (AM) स्कॉट डब्ल्यू. अंबलर द्वारा

• उपयोगकर्ता कहानी मैपिंग जेफ पैटन द्वारा – जटिल आरेखों का आधुनिक विकल्प

---

✅ एक वाक्य नियम

अनिवार्य पुनर्उपयोग के लिए «include» का उपयोग करें, वैकल्पिक विकल्प के लिए «extend» का उपयोग करें — लेकिन केवल तभी जब यह वास्तव में मूल्य जोड़ता हो। अन्यथा, इसे सरल रखें।

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

---

📌 लेखक का नोट (2025–2026):
जैसे टीमें ओर बढ़ रही हैं उत्पाद-केंद्रित, मूल्य-आधारित, और सहयोगात्मक विकास, पारंपरिक UML आरेखों की भूमिका बदल रही है। «include» और «extend» अभी भी उपयोगी हैं — लेकिन केवल तभी जब संयम, स्पष्टता और उद्देश्य के साथ उपयोग किया जाए। उन्हें उपयोगकर्ता की सेवा करनी चाहिए, आरेख की नहीं।

• उपयोग केस आरेख क्या है? – UML मॉडलिंग के लिए एक पूर्ण गाइड: यह गाइड उपयोग केस आरेखों की गहन व्याख्या प्रदान करता है, जिसमें उनके उद्देश्य, घटक और सॉफ्टवेयर आवश्यकताओं के मॉडलिंग के लिए सर्वोत्तम प्रथाओं को शामिल किया गया है।
• चरण-दर-चरण उपयोग केस आरेख ट्यूटोरियल – शुरुआत से प्रो तक: यह व्यापक संसाधन उपयोगकर्ताओं को प्रभावी उपयोग केस आरेख बनाने की प्रक्रिया के माध्यम से ले जाता है, आधारभूत अवधारणाओं से लेकर उन्नत मॉडलिंग तक।
• विजुअल पैराडाइम – उपयोग केस विवरण विशेषताएं: यह लेख विजुअल पैराडाइम में उपलब्ध विशिष्ट विशेषताओं का अध्ययन करता है जो उपयोगकर्ता अंतरक्रियाओं और प्रणाली के व्यवहार को सटीकता के साथ दस्तावेज़ीकरण के लिए उपलब्ध हैं।
• विजुअल पैराडाइम द्वारा AI उपयोग केस विवरण जनरेटर: यह पृष्ठ एक AI-संचालित उपकरण का विवरण देता है जो उपयोगकर्ता इनपुट से स्वचालित रूप से विस्तृत उपयोग केस विवरण उत्पन्न करता है, जो दस्तावेज़ीकरण प्रक्रिया को नाटकीय रूप से तेज करता है।
• विजुअल पैराडाइम में AI के साथ उपयोग केस विकास को स्वचालित करना: यह लेख बताता है कि AI-संचालित जनरेटर सॉफ्टवेयर विकास चक्र के दौरान मैन्युअल प्रयास को कम करता है और स्थिरता में सुधार करता है।
• विजुअल पैराडाइम उपयोग केस विवरण जनरेटर ट्यूटोरियल: एक चरण-दर-चरण ट्यूटोरियल जो दिखाता है कि आप अपने आरेखों से स्वचालित रूप से संरचित, विस्तृत उपयोग केस दस्तावेज़ कैसे उत्पन्न कर सकते हैं।
• विजुअल पैराडाइम में उपयोग केस का दस्तावेज़ीकरण: उपयोगकर्ता गाइड: यह आधिकारिक उपयोगकर्ता गाइड मॉडलिंग वातावरण के भीतर मान्यता प्राप्त टेम्पलेट और उत्तम व्यवहार का उपयोग करके आवश्यकताओं के प्रभावी रूप से दस्तावेजीकरण के तरीके की व्याख्या करता है।
• विजुअल पैराडाइग्म में उपयोग केस विवरण बनाना: यह तकनीकी गाइड सॉफ्टवेयर के अंतर्निहित उपकरणों के उपयोग करके सिस्टम आवश्यकताओं के लिए औपचारिक विवरण बनाने के निर्देश प्रदान करता है।
• उपयोग केस, परिदृश्य और घटनाओं के प्रवाह को समझना: यह गहन संसाधन उपयोग केस, परिदृश्य और सटीक दस्तावेजीकरण के लिए आवश्यक संरचित घटनाओं के प्रवाह के बीच महत्वपूर्ण संबंधों की व्याख्या करता है।
• प्रभावी उपयोग केस कैसे लिखें? – विजुअल पैराडाइग्म: यह ट्यूटोरियल इंगित करता है कि उपयोग केस मॉडलिंग का मुख्य उद्देश्य उपयोगकर्ता की आवश्यकताओं को स्पष्ट रूप से पहचानकर एक ठोस सिस्टम आधार बनाना है।