"उपयोग मामला", "उपयोगकर्ता कहानी" और "उपयोग परिदृश्य" में क्या अंतर है?

Question

क्या "उपयोग के मामले", "उपयोगकर्ता कहानी" और "उपयोग परिदृश्य" के बीच अंतर का एक सटीक, लेकिन सरल और समझ में आता है?

वहाँ स्पष्टीकरण का एक बहुत कुछ कर रहे हैं, लेकिन अभी, मैं कोई भी नहीं है कि एक वाक्य में अंतर बताते हैं, या दो देखते हैं ...

(उदा। http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison बहुत लंबा और कठिन है, चर्चा से भरा)

Comments

आपके सवाल के लिए धन्यवाद। किसी कारण के लिए, जो लोग कार्यप्रणाली के साथ आते हैं, वे जानबूझकर कभी भी सटीक नहीं होते हैं (मैं मानता हूं) ताकि उनके विचारों पर कभी भी कुछ स्थिति पर लागू न होने का आरोप लगाया जाए। यह पूरे उद्योग को वापस खींच रहा है, जहां हम में से प्रत्येक को एक अनुकूलन तैयार करना है जो कार्यप्रणाली का उपयोग करने से पहले काम करता है। मुझे उम्मीद है कि समुदाय इस व्यवहार के खिलाफ खड़ा होगा। कभी-कभी, आप 2 किताबें चुनते हैं और वे चीजों को अलग तरह से परिभाषित करते हैं - विज्ञान इस तरह से काम नहीं करता है।

— NoChance

मेरा सुझाव है कि आप अपनी प्रत्येक शर्तों की विकिपीडिया परिभाषा की जाँच करें। यह बेहतर तरीके से समझने में मदद कर सकता है कि शर्तों का क्या मतलब है। यह भी ध्यान दें कि शब्द विभिन्न अवधारणाओं से आते हैं। उदाहरण के लिए, उपयोगकर्ता की कहानी एक चुस्त उपकरण / तकनीक है और उपयोग मामला एक OOA उपकरण / तकनीक है।

— 15

Answer 1

एक यूजर स्टोरी एक यूज़ केस का अधिक अनौपचारिक, मित्रवत और छोटा संस्करण है , जो यूएमएल आरेख को घटाता है; यह आमतौर पर पुनरावृत्तियों में उपयोग किया जाता है।

एक उपयोग परिदृश्य एक कदम-दर-चरण प्रक्रिया में उपयोग किया जाने वाला उपयोग मामला है, कभी-कभी एक फ़्लोचार्ट के साथ।

Answer 2

मेरे लिए, उपयोगकर्ता कहानी और उपयोग प्रकरण के बीच सबसे बड़े अंतर हैं:

• एक उपयोगकर्ता कहानी एक हल्का दस्तावेज है जिसे एक कार्ड पर लिखा जा सकता है (आदेश में, एक के रूप में, मुझे चाहिए)। एक उपयोगकर्ता कहानी सभी विवरणों पर कब्जा नहीं करती है, यह चर्चा के लिए एक अनौपचारिक समर्थन है।
• एक उपयोग मामला एक हेवीवेट दस्तावेज़ है जिसे एक शब्द दस्तावेज़ की आवश्यकता होती है। यह चरणों और / या कार्यों के "सामान्य प्रवाह" और "वैकल्पिक प्रवाह" का वर्णन करता है जो विस्तृत हैं। एक उपयोग मामला सभी विवरणों को कैप्चर करता है, यह एक औपचारिक विनिर्देश है।

उपयोग परिदृश्यों पर स्कॉट डब्ल्यू। एंबलर के अनुसार , ये कलाकृतियां एक केस केस के प्रवाह की तरह दिखती हैं:

एक उपयोग परिदृश्य , या लघु के लिए परिदृश्य , एक या एक से अधिक लोगों या संगठनों द्वारा सिस्टम के साथ सहभागिता करने के वास्तविक उदाहरण का वर्णन करता है। वे उन चरणों, घटनाओं और / या कार्यों का वर्णन करते हैं जो बातचीत के दौरान होते हैं। उपयोग परिदृश्य बहुत विस्तृत हो सकते हैं, यह दर्शाता है कि कोई व्यक्ति उपयोगकर्ता इंटरफ़ेस के साथ काम करता है, या यथोचित रूप से उच्च-स्तरीय महत्वपूर्ण व्यावसायिक कार्यों का वर्णन करता है, लेकिन यह संकेत नहीं करता कि वे कैसे प्रदर्शन कर रहे हैं।

ईमानदारी से, एक प्रयोग प्रकरण के प्रवाह के साथ अंतर स्पष्ट नहीं है, इस पैराग्राफ को पढ़ने के बाद भी (अंतिम वाक्य शायद सबसे महत्वपूर्ण है):

जैसा कि आप कल्पना कर सकते हैं, उपयोग के मामलों और परिदृश्यों के बीच कई अंतर हैं। सबसे पहले, एक उपयोग का मामला आमतौर पर जेनेरिक अभिनेताओं, जैसे कि ग्राहक को संदर्भित करता है, जबकि परिदृश्य आमतौर पर जॉन स्मिथ और सैली जोन्स जैसे अभिनेताओं के उदाहरणों को संदर्भित करते हैं। जेनेरिक परिदृश्य लिखने से आपको कुछ भी नहीं रोकता है, लेकिन आमतौर पर परिदृश्यों को निजीकृत करना बेहतर होता है ताकि उनकी समझ में वृद्धि हो सके। दूसरा, उपयोग परिदृश्य तर्क के एक एकल पथ का वर्णन करते हैं, जबकि उपयोग के मामले आमतौर पर कई पथों का वर्णन करते हैं (मूल पाठ्यक्रम और किसी भी उपयुक्त वैकल्पिक पथ)। तीसरा, यूपी-आधारित प्रक्रियाओं में उपयोग किए जाने वाले मामलों को अक्सर आधिकारिक दस्तावेज के रूप में रखा जाता है जबकि परिदृश्यों को अक्सर खारिज कर दिया जाता है, क्योंकि अब उनकी आवश्यकता नहीं है।

मैं गलत हो सकता है, लेकिन उपयोग परिदृश्य वास्तव में उपयोग मामला प्रवाह की तरह लगता है, लेकिन एक चुस्त स्पर्श के साथ rebranded।

Comments

मुझे लगता है कि परिदृश्यों को निजीकृत करना हानिकारक है (कम से कम जैसा कि मैं इसे समझता हूं)। आप कहते हैं "आमतौर पर परिदृश्यों को निजीकृत करना बेहतर होता है" - लेकिन क्या होगा यदि सैली जोन्स ने कंपनी छोड़ दी या स्थिति बदल दी - परिदृश्य का क्या मूल्य होगा?

— NoChance

निजीकरण का मतलब वास्तविक व्यक्ति के लिए डिजाइनिंग नहीं है। यह एक वास्तविक व्यक्ति के लिए हो सकता है , लेकिन यह एक काल्पनिक व्यक्ति के लिए भी हो सकता है, जैसा कि "व्यक्ति" उपकरण के साथ। एक व्यक्तित्व के साथ विशिष्ट उपयोगकर्ताओं (वास्तविक या काल्पनिक) का उपयोग करने के लिए तर्क यह है कि परिदृश्य अधिक "वास्तविक" हो जाते हैं। प्रोग्रामर के लिए उपयोगकर्ता को समझना आसान होता है जब वह उस उपयोगकर्ता के व्यक्तित्व को समझता है, बजाय एक अमूर्त उपयोगकर्ता को समझने की कोशिश करने के। कृपया मुझे बताएं कि क्या मैं गलत हूं, या यदि मैंने आपकी टिप्पणी को गलत समझा।

— मैड्स स्केजर्न

के संबंध में A use case is an heavyweight document that needs a word document.। मार्टिन फाउलर सोचते हैं कि Use case are at their best when they are short and readable. You should not be spending weeks, let alone months, generating use case documents before you begin development.

— wha7ever

Answer 3

इस सामान में से किसी की भी सटीक परिभाषा नहीं है। यह सब कंपनी से कंपनी और सिस्टम से सिस्टम में थोड़ा सा (या बहुत) भिन्न होता है।

आपकी सबसे अच्छी शर्त यह है कि आप अपने वर्तमान प्रोजेक्ट के लिए पहले से ही एक उदाहरण खोजें और उसका पालन करें।

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

नामों पर लटका मत करो।

Comments

> नामों पर मत लटकाओ। चिंता मत करो, मैं नहीं होगा! :) दूसरी ओर, यह एक बहुत ही वांछनीय लक्ष्य है जब एक टीम में सभी सदस्य एक शब्द का अर्थ समान तरीके से समझते हैं और समझते हैं

मैं पूरी तरह सहमत हूं-लेकिन एक टीम स्तर पर। मुझे बस यही लगता है कि "ग्लोबल" स्तर, मैंने कभी दो लोगों को "यूज केस" को उसी तरह परिभाषित करते नहीं देखा।

— बिल के

समान नहीं है, लेकिन समान प्रवृत्तियों पर ... और यह कम से कम ये प्रवृत्तियाँ हैं जिन्हें मैं जानना और समझना चाहता था

Answer 4

एक उपयोगकर्ता कहानी हमेशा अनौपचारिक होती है और उपयोगकर्ता की आवश्यकता का वर्णन करती है। एक उपयोग का मामला औपचारिक या अनौपचारिक हो सकता है, और सिस्टम व्यवहार का वर्णन कर सकता है।

"तकनीकी" उपयोगकर्ता कहानियां होना संभव है, उपयोग के मामलों के लिए भी यह सच नहीं है।

एक बार हो जाने के बाद, उपयोगकर्ता की कहानी को आमतौर पर खारिज कर दिया जाता है। उत्पाद जीवन चक्र के दौरान उपयोग के मामलों को बनाए रखा जा सकता है।

दायरा भी अलग है। उपयोगकर्ता कहानियां आम तौर पर दायरे में छोटी होती हैं, और इसके परिणामस्वरूप एक उपयोग के मामले में कई उपयोगकर्ता कहानियां शामिल होती हैं। मौजूदा सिस्टम के लिए एक परिवर्तित आवश्यकता एक नई उपयोगकर्ता कहानी, या उपयोग के मामले के एक अद्यतन संस्करण में वर्णित है।

उपयोगकर्ता कहानियों और उपयोग मामलों के बीच समानता यह है कि दोनों का उपयोग योजना और समय-निर्धारण के लिए किया जाता है।

Answer 5

एक उपयोगकर्ता कहानी जब उन कार्यों के लिए विघटित हो जाती है जो डेवलपर्स के लिए व्यक्तिगत रूप से असाइन किए जाते हैं और उपयोग केस परिदृश्य की तुलना में अधिक दानेदार और दायरे में विवश नहीं हो सकते हैं। एक उपयोगकर्ता कहानी उपयोगकर्ता की आवश्यकता के बारे में है - एक लक्ष्य या आउटकम सिस्टम का उपयोग करके।

उपयोगकर्ता कहानियों के उदाहरण हैं:

1. मैं एक ग्राहक हूं और मैं अपना खाता शेष ऑनलाइन भुगतान करना चाहता हूं - एक बहुत उच्च-स्तरीय दृश्य
2. मैं एक ग्राहक हूं और मैं अपनी संग्रहीत क्रेडिट जानकारी पर समाप्ति वर्ष को अपडेट करना चाहता हूं - एक सुंदर दानेदार दृश्य।

अमूर्तता के उच्चतम स्तर पर एक यूज़ केस बहुत समान लगता है - ग्राहक अपडेट कार्ड समाप्ति वर्ष - लेकिन यहां लक्ष्य के बजाय फ़ंक्शन का विवरण है।

उपयोग प्रकरण परिदृश्यों की बारीकियों के रूप में परिभाषित किया गया है कि वे फ़ंक्शन और प्रक्रिया के बारे में अधिक हो जाते हैं।

उपयोग की स्थिति के मुख्य दृश्य की पोस्ट-स्थिति उसी परिणाम के रूप में होनी चाहिए जैसा कि उपयोगकर्ता कहानी में कहा गया है - ग्राहक का क्रेडिट कार्ड समाप्ति वर्ष अपडेट किया गया है।

केस परिदृश्य का उपयोग करें पाठ या प्रक्रिया प्रवाह चार्ट में या तो चरण-दर-चरण का वर्णन करें (जरूरी नहीं कि यूएमएल या बीपीएम - मैं उपयोग के मामले के अप्रशिक्षित उपभोक्ताओं द्वारा स्पष्टता और उपयोग में आसानी के लिए एक मानक क्रॉस-फ़ंक्शनल प्रवाह आरेख का उपयोग करता हूं।

लब्बोलुआब यह है कि उपयोगकर्ता कहानियां जरूरतों और परिणामों का वर्णन करती हैं (सिस्टम को क्या देने की आवश्यकता है), जबकि उपयोग मामले लक्ष्य को पूरा करने के लिए आवश्यक अभिनेताओं के बीच बातचीत का वर्णन करते हैं - और क्या गलत हो सकता है (एक्सटेंशन, वैकल्पिक या त्रुटि परिदृश्य) (उपयोगकर्ता किस तरह से बातचीत कर रहा है सिस्टम उस परिणाम को प्राप्त करता है)

इस विषय पर चर्चा की गहराई के लिए मैं एलिस्टेयर कॉकबर्न की वेबसाइट पर http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison पढ़ने का सुझाव देता हूं । चूँकि वह एजाइल मैनिफेस्टो का एक हस्ताक्षरकर्ता है, वह व्यक्ति जिसने उपयोगकर्ता कहानियों को गढ़ा है और पिछले कुछ दशकों से उपयोग केस विशेषज्ञ माना जाता है, मुझे लगता है कि वह अधिक जानकारी के लिए एक उत्कृष्ट स्रोत है।

Comments

यह सिर्फ पाठ की एक दीवार है; क्या आप इसे पठनीयता के लिए संपादित कर सकते हैं।

— मार्टिज़न पीटरर्स

Answer 6

_{त्वरित अस्थायी नोट : इस पोस्ट में प्रश्न का बेहतर उत्तर देने के लिए सुधार की आवश्यकता है, जैसे 1) संदर्भों से अतिरिक्त विवरण शामिल किए जाने चाहिए 2) कुछ उद्धरण शायद 3) अंग्रेजी की समग्र शुद्धता 4) कथा 5 की समग्र गुणवत्ता) आदि। वापस करने के लिए। इसे स्वयं सुधारने के लिए स्वतंत्र महसूस करें।}

---

उनके टेम्प्लेट पर एक नज़र डालने से इन शब्दों के बीच के अंतरों में मूल्यवान अंतर्दृष्टि मिल सकती है।

उदाहरण

उपयोग के मामलों के लिए कई टेम्पलेट हैं। मुझे त्वरित खोज के बाद 3 मिला: 1 , 2 , 3 । कुछ बिंदु वे (कभी-कभी अस्पष्ट) आम हैं:

1. उपयोग के मामले का नाम / शीर्षक
2. विवरण - कुछ लघु पाठ गुंजाइश का वर्णन।
3. अभिनेता (एस) / प्राथमिक अभिनेता - व्यक्ति (एस) जो इस विशेष उपयोग के मामले के साथ बातचीत करते हैं।
4. पूर्वधारणा - ऐसा कुछ भी जो इस उपयोग के मामले को जीवन चक्र शुरू करने से पहले सच मान सकता है।
5. सफलता परिदृश्य - घटनाओं के सही प्रवाह का वर्णन करने वाले कदम का एक क्रम।

6. एक्सटेंशन - सफलता के प्रवाह के प्रवाह से विचलित होने पर आवेदन का प्रवाह:

   1. वैकल्पिक प्रवाह - सही प्रवाह के अन्य विकल्प
   2. अपवाद प्रवाह - घटनाओं के प्रवाह के लिए जब चीजें गलत हो जाती हैं

7. सफलता की गारंटी (उर्फ। पोस्ट की स्थिति) - सब कुछ होने के बाद आवेदन की स्थिति

शामिल किए जाने वाले कुछ अतिरिक्त बिंदु स्तर , न्यूनतम गारंटी , ट्रिगर , आदि हैं।

ऊपर जिसे पूरी तरह से कपड़े पहने उपयोग मामला कहा जाता है । आप उदाहरण के लिए केवल सबसे महत्वपूर्ण बिंदुओं का उपयोग करके एक आकस्मिक उपयोग के मामले का उपयोग करके केस निर्माण को सरल बना सकते हैं :

1. शीर्षक
2. अभिनेता (रों)
3. घटनाओं के अनुक्रम

उपयोग के मामले 90 के दशक के उत्तरार्ध में 90 के दशक के अंत में इवर जैकबसन द्वारा बनाए और लोकप्रिय किए गए थे। बाद में अन्य लोगों ने भी उनके काम में योगदान दिया (ऐसे लोगों में से एक एलिस्टेयर कॉकबर्न हैं जो राइटिंग इफेक्टिव यूज़ केस के लेखक हैं )। करने के लिए मार्टिन Fowler व्याख्या उपयोग के मामलों में यह के पाठ में पाठ और यूएमएल चित्र, लेकिन उनकी सबसे बड़ी मूल्य झूठ का उपयोग कर सकते हैं। वे सबसे अच्छे होते हैं जब वे बड़े और पढ़ने में आसान नहीं होते हैं।

उपयोगकर्ता कहानी _{(उर्फ। फ़ीचर)}

उपयोगकर्ता कहानी - एक छोटी कहानी जो किसी विशेष विशेषता का वर्णन करती है। उपयोगकर्ता कहानी लिखने का एक सामान्य तरीका है, जो है:

एक विशेष प्रकार के उपयोगकर्ता के रूप में
मैं कुछ करना चाहता हूं
ताकि कुछ कारण हो ।

इसके अलावा, उपयोगकर्ता कहानी में स्वीकृति मानदंड हो सकते हैं ।

जैसा कि आप देख सकते हैं कि यह टेम्पलेट उपयोग के मामले की तुलना में बहुत छोटा है। आमतौर पर उपयोगकर्ता कहानियां सॉफ्टवेयर डेवलपमेंट के क्षेत्र / फुर्तीली / xp क्षेत्र से जुड़ी होती हैं। वे सतह के छोटे क्षेत्रों, जैसे कि पोस्ट-इट नोट्स, और / या स्क्रैम बोर्ड पर लिखे जाते हैं। वहां, वे (आमतौर पर) दिए गए बिंदु मान हैं जो अनुमानित करते हैं कि उस उपयोगकर्ता कहानी ^रेफ में कितना प्रयास करने की आवश्यकता है ।

बिल वेक ने एक अच्छी उपयोगकर्ता कहानी में कौन से गुण होने चाहिए, इसका वर्णन करने के लिए INVEST mnemonic विकसित किया है, और मैं अपनी वेबसाइट से मार्टिन फाउलर का संक्षिप्त सारांश उधार लूंगा :

स्वतंत्र : कहानियों को किसी भी क्रम में वितरित किया जा सकता है
परक्राम्य : कहानी के विकास में प्रोग्रामर और ग्राहक द्वारा सह-निर्मित किए गए विवरणों का विवरण है।
मूल्यवान : कार्यक्षमता को सॉफ़्टवेयर के ग्राहकों या उपयोगकर्ताओं द्वारा मूल्यवान माना जाता है।
बहुमूल्य : प्रोग्रामर कहानी के निर्माण के लिए एक उचित अनुमान के साथ आने कर सकते हैं
छोटे : कहानियों समय की एक छोटी राशि, व्यक्ति-दिनों की आम तौर पर एक मामले में बनाया जाना चाहिए। निश्चित रूप से आपको एक पुनरावृत्ति के भीतर कई कहानियाँ बनाने में सक्षम होना चाहिए।
परीक्षण योग्य : आपको इस कहानी के सही ढंग से काम करने के लिए सॉफ्टवेयर को सत्यापित करने के लिए परीक्षण लिखने में सक्षम होना चाहिए।

उपयोग परिदृश्य

उपयोग परिदृश्य GWT पैटर्न का अनुसरण करता है जो कि दिए गए-जब-तब के लिए खड़ा है, जैसे:

परिदृश्य : शीर्षक
दिया : एक विशेष तथ्य
और : एक और विशेष तथ्य (वैकल्पिक हो सकता है)
जब : कुछ घटना होती है
तब : कुछ अन्य घटना होती है

उपयोग परिदृश्य व्यवहार-प्रेरित विकास के साथ जुड़े हुए हैं। यह एक परीक्षण के समान लगता है। अपने ब्लॉग पोस्ट में मार्टिन फाउलर उपयोग परिदृश्यों के पीछे कुछ इतिहास और तर्क देता है। यहाँ महत्वपूर्ण हिस्सा है:

दिए गए हिस्सा दुनिया की स्थिति का वर्णन करता है इससे पहले कि आप व्यवहार आप इस परिदृश्य में निर्दिष्ट कर रहे हैं शुरू करते हैं। आप इसे परीक्षण के लिए पूर्व स्थितियों के रूप में सोच सकते हैं। जब खंड है कि व्यवहार है कि आप निर्दिष्ट कर रहे है। अंत में तत्कालीन अनुभाग निर्दिष्ट व्यवहार के कारण आपके द्वारा अपेक्षित परिवर्तनों का वर्णन करता है।

उपयोग परिदृश्यों का उपयोग आपके आवेदन के लिए परीक्षण लिखने के लिए किया जा सकता है। मार्टिन के पोस्ट के अंतिम पैराग्राफ को उद्धृत करने के लिए:

यद्यपि गिविंग-जब-तब शैली बीडीडी के लिए रोगसूचक है, उदाहरण के लिए परीक्षण या विनिर्देश लिखते समय मूल विचार बहुत सामान्य है। Meszaros चार-चरण परीक्षण के रूप में पैटर्न का वर्णन करता है। उनके चार चरण हैं सेटअप (दिया गया), व्यायाम (कब), सत्यापित (तब) और आँसू। बिल वेक अरेंजमेंट, एक्ट, एस्टर के रूप में तैयार हुआ।

---

आगे के अध्ययन के लिए संदर्भ:

के लिए विकिपीडिया पृष्ठों उपयोग के मामले , उपयोगकर्ता कहानी , उपयोग परिदृश्य
पर मार्टिन Fowler के ब्लॉग उपयोग के मामले , उपयोगकर्ता कहानी , उपयोग परिदृश्य

Answer 7

मैं यूजर स्टोरी से परिचित नहीं हूं, लेकिन जब मैंने कई साल पहले इस पर ध्यान दिया था:

एक उपयोग मामला एक प्रमुख कार्य है।
उपयोगकर्ता परिदृश्य विभिन्न तरीके हैं जो कार्य कर सकते हैं। इसलिए, हर उपयोग मामले में एक या अधिक परिदृश्य होते हैं। उपयोग मामला सार है, उपयोगकर्ता परिदृश्य उस सार कार्य के सभी संभावित उदाहरणों की एक सूची है।

इसलिए:
केस ए का उपयोग करें: उपयोगकर्ता आईडी और पासवर्ड के साथ प्रमाणित करता है।

परिदृश्य:
1. आईडी मान्यता प्राप्त है, पासवर्ड सही है। ("सनी डे" परिदृश्य)
2. आईडी मान्यता प्राप्त है, पासवर्ड गलत है।
3. आईडी मान्यता प्राप्त है, पासवर्ड तीसरी बार गलत है।
4. पहचान नहीं है आईडी।

मैंने हमेशा मामलों को क्लाइंट के लिए उनकी शर्तों में एक कथात्मक तरीके से परिभाषित करने के तरीके के रूप में उपयोग करने के बारे में सोचा है। w / r / t ऊपर, अगर क्लाइंट कहता है "लेकिन क्या होगा अगर वे सिस्टम के डाउन होने पर आधी रात और एक के बीच में लॉग इन करने की कोशिश करते हैं?", हमने प्रमाणीकरण कार्य के लिए एक और परिदृश्य और कुछ अतिरिक्त आवश्यकताओं की खोज की है।

Answer 8

उपयोगकर्ता की कहानी ग्राहक के दृष्टिकोण से होती है, कभी-कभी यह गलत या अधूरी होती है। इसमें प्रदर्शन पर कोई त्रुटि, त्रुटि से निपटने या बैकएंड पर कुछ भी नहीं हो सकता है।

एक उपयोग का मामला देव के दृष्टिकोण से है। यह सटीक और पूर्ण है। यह ग्राहकों से सभी आवश्यकताओं का जवाब देना चाहिए।

Answer 9

"उपयोग मामला" और "उपयोगकर्ता कहानी" इस अर्थ में समान हैं कि वे ग्राहक की "आवश्यकताओं" का प्रतिनिधित्व करते हैं।

उपयोग मामला वह तरीका है जो सिस्टम प्रत्येक मामले में उपयोग किया जाता है, सामान्य रूप से अभिनेता और सिस्टम के बीच या सिस्टम के बीच बातचीत के रूप में प्रतिनिधित्व किया जाता है।

उपयोगकर्ता कहानी एक कंप्यूटर एडेड टूल बनाने के लिए यात्रा में शुरुआती बिंदु है जो अंत-उपयोगकर्ता को कुछ करने में सक्षम करेगा, और आम तौर पर एक सरल वाक्य के साथ शुरू होता है कि कौन, क्या, क्यों ("एक उपयोगकर्ता द्वारा एप्लिकेशन को बंद करने के रूप में, मुझे चाहिए अंतिम बचत के बाद से जो कुछ भी बदल गया है उसे बचाने के लिए प्रेरित किया जाए ताकि मैं उपयोगी कार्य को संरक्षित कर सकूं और गलत काम को छोड़ सकूं। ")। उस उपयोगकर्ता कहानी को तब उपयोग के मामले में विकसित करने की आवश्यकता होती है जो डेवलपर्स एक एप्लिकेशन बनाने के लिए नियोजित करते हैं, और परीक्षण करने के लिए परीक्षक।

क्यूए परीक्षक के दृष्टिकोण से, वे "उपयोगकर्ता कहानियों" का परीक्षण नहीं कर रहे हैं, बल्कि "मामलों का उपयोग करें", जिसका अर्थ है कि वे सॉफ्टवेयर कार्यात्मकताओं का परीक्षण कर रहे हैं।

Comments

सही होने पर, यह उन उत्तरों के लिए कुछ भी नहीं जोड़ता है जो 4 साल से पहले से ही हैं।

— एडम ज़ुकरमैन

Answer 10

उपयोग परिदृश्य का उद्देश्य सिस्टम क्रियाओं या वास्तविक डिज़ाइन के विवरण में गोताखोरी के बिना, एक लक्ष्य को प्राप्त करने के लिए आपके सिस्टम के साथ उपयोगकर्ता इंटरैक्शन का सार कैप्चर करना है। ध्यान उपयोगकर्ता पर है, सिस्टम पर नहीं।

... उपयोग प्रकरण में सिस्टम क्या करेगा के बारे में बयान भी शामिल हैं, जबकि उपयोग परिदृश्य इस चर्चा से बचेंगे।

आपने अभी तक यह निर्धारित नहीं किया है कि आप इसे कैसे लागू करने जा रहे हैं।

से उत्पाद-कला साइट।

Comments

यह स्वीकृत उत्तर के ऊपर और परे कुछ भी नहीं जोड़ता है जो सात साल से अधिक समय पहले पोस्ट किया गया था। इसके अलावा, सूत्रों को उद्धृत करना अच्छा है, लेकिन इसे अपने शब्दों में समझाना बेहतर होगा: पाठ का आपके लिए क्या मतलब है?

बस स्पष्ट होना: पुराने प्रश्नों के उत्तर देने में कुछ भी गलत नहीं है। स्टैक एक्सचेंज में एक एंटी-नेक्रोमेंसी पॉलिसी नहीं है। लेकिन अगर आपको चर्चा में देर हो रही है, तो कृपया नई जानकारी जोड़ना सुनिश्चित करें, संभवतः वह जानकारी जो सात साल पहले उपलब्ध नहीं थी।