User stories, use cases, job stories और requirement statements सॉफ्टवेयर को क्या करना चाहिए, इसे लिखने के चार तरीके हैं। उन्हें अक्सर प्रतिद्वंद्वियों के रूप में प्रस्तुत किया जाता है, लेकिन वे विभिन्न स्तरों की विस्तृतता पर विभिन्न प्रश्नों के उत्तर देते हैं। एक user story पूछता है कि कौन क्या चाहता है और क्यों। एक use case एक इंटरैक्शन को चरण-दर-चरण से गुज़रता है, जिसमें यह भी शामिल है कि क्या गलत हो सकता है। एक job story उपयोगकर्ता की स्थिति से शुरू होती है। एक requirement एक नियम बताता है जिसे सिस्टम का पालन करना चाहिए।
यह गाइड इन चारों की तुलना करती है, एक ही फीचर को प्रत्येक तरीके से लिखा दिखाती है, और समझाती है कि कब कौन सा उपयोग करना है। कहानियाँ लिखने के मूल बातों के लिए, हमारे हब गाइड पर देखें यूज़र स्टोरीज़ कैसे लिखें.
त्वरित तुलना
| यूज़र स्टोरी | Use case | Job story | Requirement statement | |
|---|---|---|---|---|
| प्रारूप | एक [उपयोगकर्ता] के रूप में, मैं [क्रिया] करना चाहता हूँ, ताकि [लाभ] | अभिनेता, लक्ष्य, पूर्व-शर्तें, मुख्य सफलता परिदृश्य, विस्तार, पोस्ट-शर्तें | जब [स्थिति], मैं [प्रेरणा] करना चाहता हूँ, ताकि मैं [अपेक्षित परिणाम] कर सकूँ | सिस्टम को [व्यवहार या प्रतिबंध] करना चाहिए |
| केंद्रित | उपयोगकर्ता का एक प्रकार और उनका लक्ष्य | एक अभिनेता और सिस्टम के बीच इंटरैक्शन | स्थिति और प्रेरणा, पर्सोना नहीं | सिस्टम का व्यवहार या गुणवत्ता |
| लंबाई | एक वाक्य और स्वीकृति मानदंड | आधा पेज से कई पेज तक | एक वाक्य | प्रति आवश्यकता एक वाक्य, प्रति दस्तावेज़ कई |
| उद्गम | Extreme Programming; Connextra (2001) से प्रारूप | Ivar Jacobson (1980 के दशक के अंत); Alistair Cockburn का लक्ष्य-आधारित शैली (2000) | Paul Adams at Intercom; Alan Klement द्वारा विकसित (2013) | पारंपरिक आवश्यकता इंजीनियरिंग (आज ISO/IEC/IEEE 29148) |
| सबसे अच्छा किसके लिए | एजिल बैकलॉग और स्प्रींट योजना | जटिल प्रवाह, एकीकरण, नियमित या अनुबंध कार्य | डिस्कवरी और डिज़ाइन, विशेष रूप से एक ही स्थिति में विविध उपयोगकर्ताओं के लिए | गैर-कार्यात्मक आवश्यकताएं, अनुपालन, निश्चित-विशाल अनुबंध |
| कमज़ोर है | पूरा प्रवाह और एज केस दिखाते हुए | गति; तेज़ पुनरावृत्ति में अपडेट रखना कठिन | स्वयं योजना और अनुमान लगाना | कारण समझाना; परीक्षण योग्य सूची लिखना आसान |
उपयोगकर्ता कहानियाँ
एक उपयोगकर्ता कहानी क्षमता का एक संक्षिप्त विवरण है, जिसे उस व्यक्ति के दृष्टिकोण से बताया गया है जो उसे चाहता है। सामान्य प्रारूप, “एक [उपयोगकर्ता प्रकार] के रूप में, मैं [कार्य] करना चाहता हूँ, ताकि [लाभ]”, 2001 में Connextra टीम से आया और माइक कोह्न की पुस्तक User Stories Applied के माध्यम से फैला। कहानियाँ Extreme Programming में विकसित हुईं, जहाँ वे जानबूझकर संक्षिप्त थीं: रॉन जेफ्रीज़ ने प्रत्येक कहानी को एक कार्ड, एक संवाद और एक पुष्टि के रूप में वर्णित किया (3 Cs)। कार्ड विनिर्देश नहीं है; संवाद वह जगह है जहाँ विवरण सहमति से तय होते हैं, और स्वीकृति मानदंड उन्हें पुष्ट करते हैं।
बल: कहानियाँ इतनी छोटी होती हैं कि उन्हें एक स्प्रींट में अनुमानित और पूरा किया जा सकता है, गैर-तकनीकी हितधारकों के लिए पढ़ना आसान होता है, और मूल्य (“ताकि”) को दृष्टि में रखती हैं। माइक कोह्न ने उनका मामला इसमें रखा है आवश्यकताओं के लिए उपयोगकर्ता कहानियों के लाभ.
सीमाएं: व्यक्तिगत कहानियों का बैकलॉग यह नहीं दिखाता कि वे एक प्रवाह में कैसे जुड़ते हैं, और प्रारूप गलती के मामलों को छोड़ना आसान बनाता है। टीम पहले को ठीक करती है उपयोगकर्ता कहानी नक्शा और दूसरे को अच्छी तरह लिखे गए स्वीकृति मानदंडों के साथ (हमारे देखें उपयोगकर्ता कहानी टेम्पलेट).
उपयोग केस
एक उपयोग केस यह वर्णन करता है कि एक एक्टर (एक व्यक्ति या कोई अन्य सिस्टम) लक्ष्य प्राप्त करने के लिए सिस्टम का उपयोग कैसे करता है, चरणों की एक अनुक्रम के रूप में, साथ ही उस अनुक्रम के शाखा या विफल होने के तरीके भी। इवार् जैकॉबसन ने 1980 के दशक के अंत में उपयोग केस पेश किए, और एलिस्टेयर कॉकबर्न की पुस्तक Writing Effective Use Cases (2000) ने लक्ष्य-केंद्रित, सादा-पाठ शैली तय की जो आज अधिकांश टीमों द्वारा उपयोग की जाती है (कॉकबर्न की वेबसाइट).
एक पूर्ण उपयोग केस में आमतौर पर शामिल होता है:
- प्राथमिक एक्टर: कौन संवाद शुरू करता है।
- लक्ष्य और दायरा: एक्टर क्या चाहता है और किस सिस्टम का वर्णन किया जा रहा है।
- पूर्व-शर्तें: क्या पहले से सत्य होना चाहिए।
- ट्रिगर: क्या उपयोग केस को शुरू करता है।
- मुख्य सफलता परिदृश्य: जब सब कुछ सही जाता है तो संख्यांकित चरण।
- विस्तार: वैकल्पिक और विफलता पथ, प्रत्येक उस चरण से जुड़ा जहाँ वे शाखा लेते हैं।
- पश्च-शर्तें या गारंटी: सफलता और विफलता पर अंत में क्या सत्य होता है।
बल: विस्तार अनुभाग आपको गलत होने वाली चीज़ों के बारे में सोचने के लिए मजबूर करता है, और पूरा प्रवाह एक ही जगह पर दृश्यमान होता है, जो एकीकरण, भुगतान, और किसी भी ऑडिटेड चीज़ के लिए मूल्यवान है। सीमाएं: उपयोग केस लिखने और अपडेट रखने में अधिक समय लगता है, और एक उपयोग केस आमतौर पर एक स्प्रींट में बनाने के लिए बहुत बड़ा होता है।
उपयोग केस एजिल कार्य के अनुकूल हो गए हैं। Use-Case 2.0में, जैकॉबसन और सहयोगियों ने प्रत्येक उपयोग केस को “स्लाइस” में विभाजित किया, प्रत्येक इतना छोटा कि उसे योजनाबद्ध और परीक्षण किया जा सके, जो उपयोगकर्ता कहानियों के समान भूमिका निभाते हैं।
जॉब कहानियाँ (करने के लिए काम)
एक जॉब कहानी पर्सोना की जगह स्थिति लेती है: “जब [स्थिति], मैं [प्रेरणा] करना चाहता हूँ, ताकि मैं [अपेक्षित परिणाम] कर सकूँ।” यह विचार पहले पॉल एडम्स ने Intercom ब्लॉग पर उठाया और एलन क्लेमंट ने विकसित किया, जिन्होंने 2013 के Intercom गेस्ट पोस्ट में इसका विवरण दिया, फ़ीचर डिज़ाइन के लिए जॉब कहानियों का उपयोग। यह फ़ीचर डिज़ाइन पर jobs-to-be-done विचार को लागू करता है, जो क्लेटन क्रिस्टेंसेन से जुड़ा है।
जॉब कहानियों के पक्ष में तर्क यह है कि “एक व्यस्त माता-पिता के रूप में” मान्यताएँ वह टीम परीक्षण नहीं कर सकती, जबकि स्थिति (“जब मैं घर से निकलने वाला हूँ और मुझे एहसास होता है कि मैंने किराना ऑर्डर करना भूल गया”) अत्यावश्यकता, प्रतिबंध और उपयोगकर्ता के लिए “पूर्ण” कैसा महसूस होता है, को समझाता है। एक ही स्थिति में दो बहुत अलग पर्सोना अक्सर एक ही चीज़ की आवश्यकता रखते हैं।
बल: जॉब कहानियाँ डिस्कवरी और डिज़ाइन में अच्छी होती हैं, टीम को संदर्भ पर केंद्रित रखती हैं, और ग्राहक साक्षात्कार के लिए बेहतर प्रश्न उत्पन्न करती हैं। सीमाएं: वे यह कम बताती हैं कि कौन क्या करने की अनुमति रखता है, जो अनुमतियों और भूमिकाओं के लिए महत्वपूर्ण है, और अधिकांश टीमें अभी भी उन्हें योजना के लिए उपयोगकर्ता कहानियों या कार्य में बदल देती हैं।
आवश्यकता कथन
पारंपरिक प्रारूप एक संख्यांकित कथन है: “सिस्टम पाँच असफल साइन-इन प्रयासों के बाद एक खाते को लॉक करेगा।” नियमित उद्योगों, सरकारी टेंडर और निश्चित-मूल्य अनुबंधों में आवश्यकता विनिर्देश अभी भी मानक हैं, और उन्हें लिखने का वर्तमान अंतर्राष्ट्रीय मानक ISO/IEC/IEEE 29148 है।
एजिल टीम भी आवश्यकता कथन का उपयोग करती हैं, मुख्य रूप से गैर-कार्यात्मक आवश्यकताओं (प्रदर्शन, सुरक्षा, उपलब्धता, सुगम्यता) के लिए जो कई कहानियों पर लागू होती हैं। इन्हें अक्सर एक बार, 'definition of done' या एक छोटी गुणवत्ता-गुणधर्म पृष्ठ में दर्ज किया जाता है, न कि हर कहानी पर दोहराया जाता है।
एक ही फ़ीचर तीनों तरीकों से लिखा गया
फ़ीचर: एक साझा खर्च ऐप में, एक व्यक्ति कुछ खरीदता है और अन्य लोगों के साथ लागत का बँटवारा करता है।
एक उपयोगकर्ता कहानी के रूप में
एक ऐसा व्यक्ति जो साझा खरीद के लिए भुगतान करता है, मैं चाहता हूँ कि लागत का बँटवारा उन लोगों के साथ किया जाए जिनके लिए वह खरीद की गई थी, ताकि हर किसी का बैलेंस दिखाए कि वे मुझे कितना देनदार हैं।
- मैं चुन सकता हूँ कि कौन से समूह सदस्य लागत साझा करेंगे; मैं डिफ़ॉल्ट रूप से शामिल हूँ।
- डिफ़ॉल्ट बँटवारा समान होता है; मैं सटीक राशियों या प्रतिशतों पर स्विच कर सकता हूँ।
- ऐप वह बँटवारा सहेज नहीं करेगा जिसके हिस्से कुल राशि के बराबर न हों, और यह बताएगा कि वह कितना कम है।
- जैसे ही खर्च सहेजा जाता है, हर व्यक्ति का बैलेंस अपडेट हो जाता है, और उन्हें एक नोटिफिकेशन मिलता है।
एक उपयोग केस के रूप में
उपयोग केस: खर्च का बँटवारा करें। प्राथमिक अभिनेता: भुगतान करने वाला। पूर्व शर्त: भुगतान करने वाला साइन इन है और कम से कम एक अन्य सदस्य वाले समूह का हिस्सा है। ट्रिगर: भुगतान करने वाला “खर्च जोड़ें” चुनता है।
- भुगतान करने वाला राशि, विवरण और तिथि दर्ज करता है।
- सिस्टम समूह सदस्यों को दिखाता है, जिसमें भुगतान करने वाला चयनित होता है।
- भुगतान करने वाला उन सदस्यों का चयन करता है जो लागत साझा करते हैं।
- सिस्टम समान बँटवारा का प्रस्ताव रखता है और हर हिस्सा दिखाता है।
- भुगतान करने वाला पुष्टि करता है।
- सिस्टम खर्च को सहेजता है, हर बैलेंस को अपडेट करता है और चयनित सदस्यों को सूचित करता है।
- 4a. भुगतान करने वाला सटीक राशियों या प्रतिशतों पर स्विच करता है: सिस्टम हर मान टाइप होने पर पुनः गणना करता है।
- 5a. हिस्से कुल राशि के बराबर नहीं होते: सिस्टम सहेजने को रोकता है और अंतर दिखाता है।
- 6a. डिवाइस ऑफ़लाइन है: सिस्टम खर्च को स्थानीय रूप से सहेजता है, इसे लंबित के रूप में चिह्नित करता है और ऑनलाइन होने पर सिंक करता है।
- सफलता पर पोस्टकंडिशन: खर्च एक बार दर्ज किया जाता है, और हर बैलेंस में इसका प्रतिबिंब होता है। विफलता पर: कोई बैलेंस परिवर्तन नहीं होता।
एक जॉब स्टोरी के रूप में
जब मैंने अभी-अभी किराने के काउंटर पर कुछ खरीदा है जिसमें मेरे फ्लैटमेट्स का हिस्सा भी शामिल है, तो मैं राशि भूलने से पहले इसे दर्ज करना चाहता हूँ, ताकि मैं किसी को पीछे नहीं लगाकर अपना पैसा वापस ले सकूँ।
रिक्वायरमेंट स्टेटमेंट्स के रूप में
- REQ-1: सिस्टम को एक ग्रुप सदस्य को राशि, विवरण, तिथि और भुगतानकर्ता के साथ खर्च दर्ज करने की अनुमति देनी चाहिए।
- REQ-2: सिस्टम को भुगतानकर्ता को खर्च को समान रूप से, सटीक राशियों के आधार पर या प्रतिशत के आधार पर विभाजित करने की अनुमति देनी चाहिए।
- REQ-3: सिस्टम को उस विभाजन को अस्वीकार करना चाहिए जिसके भाग कुल राशि के बराबर न हों।
- REQ-4: सिस्टम को सेव करने के दो सेकंड के भीतर सभी प्रभावित बैलेंस अपडेट करना चाहिए।
देखें कि हर संस्करण ने क्या उजागर किया। यूज़र स्टोरी अनुमान लगाने और योजना बनाने के लिए सबसे आसान है। यूज़ केस एकमात्र है जिसने ऑफलाइन स्थिति को उठाया और यह बताया कि यदि सेव विफल हो तो क्या सत्य होना चाहिए। जॉब स्टोरी ने वास्तविक प्रतिबंध को उजागर किया, जो किराने के काउंटर पर गति है; इसका सुझाव है कि पहली स्क्रीन को केवल राशि पूछनी चाहिए और कुछ नहीं, जो अन्य किसी भी संस्करण ने प्रेरित नहीं किया होता। रिक्वायरमेंट्स ने एक मापनीय प्रदर्शन लक्ष्य जोड़ा जो कहानी में अप्रत्यक्ष था।
आपको कौन सा उपयोग करना चाहिए?
| स्थिति | इससे शुरू करें | क्यों |
|---|---|---|
| प्रारंभिक खोज, इंटरव्यू, निर्धारित करना कि क्या बनाना है | जॉब स्टोरीज़ | वे टीम को यूज़र के संदर्भ पर बनाए रखते हैं और बेहतर इंटरव्यू प्रश्न बनाते हैं |
| एजिल प्रोडक्ट बैकलॉग, स्प्रींट प्लानिंग | स्वीकृति मानदंडों के साथ यूज़र स्टोरीज़ | छोटी, अनुमान योग्य, और सभी द्वारा पढ़नी योग्य |
| एक जटिल प्रवाह, एक एकीकरण, पैसे का आदान-प्रदान | एक यूज़ केस, फिर इसे स्टोरीज़ में विभाजित करें | विस्तार तब तक विफलता पथों को उजागर करते हैं जब तक वे बग नहीं बन जाते |
| नियंत्रित उत्पाद, सार्वजनिक टेंडर, निश्चित-मूल्य अनुबंध | आवश्यकता कथन, अक्सर उपयोग मामलों से संबंधित | ऑडिटर और अनुबंधों को संख्यांकित, सत्यापनीय कथनों की आवश्यकता होती है |
| प्रदर्शन, सुरक्षा, सुगम्यता लक्ष्य | आवश्यकता कथन या 'काम पूरा होने की परिभाषा' | वे कई कहानियों पर लागू होते हैं, केवल एक पर नहीं |
| छोटी टीम के साथ MVP | उपयोगकर्ता कहानियों की एक कहानी नक्शा, जिसमें सबसे जोखिमपूर्ण प्रवाह के लिए एक उपयोग मामला | तेज़ी से दायरा तय करने और निर्माण करने के लिए पर्याप्त संरचना |
क्या आप इन्हें संयोजित कर सकते हैं?
हाँ, और अधिकांश परिपक्व टीमों ऐसा करती हैं। एक कार्यात्मक अनुक्रम इस प्रकार दिखता है:
- अनुसंधान करते समय जॉब कहानियों का उपयोग करें, ताकि वास्तविक उपयोगकर्ताओं से स्थितियों और प्रेरणाओं को दर्ज किया जा सके।
- नतीजतन क्षमताओं को एक कहानी नक्शा के रूप में उपयोगकर्ता कहानियों के रूप में व्यवस्थित करें, और पहले रिलीज़ स्लाइस का चयन करें।
- उन एक या दो प्रवाहों के लिए जहाँ विफलता महंगी होती है (भुगतान, साइन-अप, डेटा सिंक), विस्तारों को खोजने के लिए एक हल्का उपयोग मामला लिखें, फिर प्रत्येक विस्तार को अपनी कहानी या स्वीकृति मानदंड के रूप में बदलें।
- क्रॉस-कटिंग आवश्यकताओं (प्रदर्शन, सुरक्षा, सुगम्यता, अनुपालन) को एक बार संख्यांकित कथनों के रूप में या 'काम पूरा होने की परिभाषा' में दर्ज करें।
सूत्र: केवल उतना ही लिखें जितना टीम को सही चीज़ को सुरक्षित रूप से बनाने के लिए आवश्यक हो। तीन सदस्यीय MVP टीम को आवश्यकता दस्तावेज़ की आवश्यकता नहीं होती है, और बैंक एकीकरण एक ही वाक्य पर निर्भर नहीं होना चाहिए।
सामान्य गलतियाँ
- उपयोगकर्ता-इंटरफ़ेस स्क्रिप्ट के रूप में उपयोग मामलों को लिखना (“उपयोगकर्ता नीले बटन पर क्लिक करता है”), जो आवश्यकता को एक ऐसे डिज़ाइन से जोड़ता है जो बदल जाएगा।
- “so that” के बिना यूज़र स्टोरी लिखना, जिससे टीम को एक सरल समाधान सुझाने में असमर्थता होती है।
- जॉब स्टोरी को एक छिपे हुए पर्सोना के रूप में देखना (“जब मैं एक व्यस्त माँ हूँ...”)। स्थिति एक क्षण होना चाहिए, न कि एक पहचान।
- एक लंबी आवश्यकताओं की सूची को बैकलॉग में एक लाइन पर एक स्टोरी के रूप में कॉपी करना, जिससे उपयोगकर्ता और मूल्य के बिना स्टोरी बनती हैं।
- एक ही बैकलॉग में विभिन्न प्रारूपों का उपयोग करना, जिसमें यह तय नहीं होता कि सत्य का स्रोत कौन सा है।
अक्सर पूछे जाने वाले प्रश्न
यूज़र स्टोरी और यूज़ केस के बीच मुख्य अंतर क्या है?
यूज़र स्टोरी एक वाक्य का विवरण है जो बताता है कि कौन किस क्षमता को क्यों चाहता है, जिसका उपयोग कार्य की योजना और प्राथमिकता निर्धारण के लिए किया जाता है। यूज़ केस एक एक्टर और सिस्टम के बीच अंतर्क्रिया का चरण-दर-चरण विवरण है, जिसमें वैकल्पिक और विफलता पथ भी शामिल हैं। स्टोरी छोटी और कम विस्तृत होती हैं; जबकि यूज़ केस पूरा प्रवाह दिखाते हैं।
क्या यूज़र स्टोरी एक आवश्यकता है?
यह आवश्यकता को कैप्चर करने का एक हल्का तरीका है, लेकिन यह एक पूर्ण विनिर्देशन नहीं है। विवरण संवाद और स्वीकृति मानदंडों में रहते हैं। प्रदर्शन और सुरक्षा जैसे गैर-कार्यात्मक आवश्यकताओं को अक्सर अलग से दर्ज किया जाता है।
क्या एजिल टीमों में अभी भी यूज़ केस का उपयोग किया जाता है?
हाँ, मुख्य रूप से जटिल या उच्च-जोखिम वाले प्रवाहों के लिए। Ivar Jacobson और सहयोगियों द्वारा विकसित Use-Case 2.0, यूज़ केस को स्लाइस में विभाजित करता है जिन्हें यूज़र स्टोरी की तरह योजनाबद्ध किया जा सकता है, ताकि दोनों एक ही बैकलॉग में रह सकें।
जॉब स्टोरी और यूज़र स्टोरी के बीच अंतर क्या है?
यूज़र स्टोरी उपयोगकर्ता के प्रकार से शुरू होती है (“As a...”)। जॉब स्टोरी एक स्थिति (“When...”) से शुरू होती है, और प्रेरणा और अपेक्षित परिणाम पर केंद्रित होती है। जॉब स्टोरी jobs-to-be-done विचारधारा से आती हैं और खोज और डिज़ाइन में सबसे उपयोगी होती हैं।
क्या एक यूज़ केस कई यूज़र स्टोरी बन सकता है?
हाँ। मुख्य सफलता परिदृश्य अक्सर एक या दो स्टोरी बन जाता है, और प्रत्येक महत्वपूर्ण विस्तार अपनी स्वतंत्र स्टोरी या स्वीकृति मानदंड बन जाता है। यह एक विश्वसनीय तरीका है जिससे बड़ी फीचर को बिना किनारे के मामलों (edge cases) को खोए विभाजित किया जा सकता है।
यूज़ केस और टेस्ट केस के बीच अंतर क्या है?
यूज़ केस वर्णन करता है कि सिस्टम को एक्टर के लक्ष्य को पूरा करने के लिए कैसे व्यवहार करना चाहिए। टेस्ट केस उस व्यवहार के माध्यम से एक विशिष्ट पथ की जांच करता है, जिसमें विशिष्ट इनपुट और अपेक्षित परिणाम शामिल होते हैं। एक यूज़ केस से आमतौर पर कई टेस्ट केस बनते हैं।
नहीं पता कि आपके उत्पाद को कितना विनिर्देशन चाहिए? हम फाउंडर्स को विचारों को एक परिभाषित बैकलॉग में बदलने और फिर छोटे स्पिंट्स में इसे बनाने में मदद करते हैं। देखें हमारे मासिक डेवलपमेंट प्लान.