लाभ:
- कृत्रिम बुद्धिमत्ता की सहायता से कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं में अंतर करने और स्पष्ट, मापने योग्य आवश्यकता अभिव्यक्तियाँ लिखने की क्षमता
- साक्षात्कार नोट्स से उपयोगकर्ता की कहानी, स्वीकृति मानदंड और दायरे की सीमा निकालने के लिए संरचित संकेतों के साथ कृत्रिम बुद्धिमत्ता का उपयोग करने की क्षमता
- अस्पष्टता, विरोधाभास और लापता नियमों के लिए एआई-जनित आवश्यकताओं की जांच करने और हितधारकों के साथ उनकी पुष्टि करने की आदत डालना
आवश्यकताओं का विश्लेषण पूर्ण, स्पष्ट और सत्यापन योग्य तरीके से परिभाषित करने का कार्य है कि एक सिस्टम को क्या करना चाहिए। यह उन चरणों में से एक है जहां एमआईएस विशेषज्ञ सबसे अधिक मूल्य उत्पन्न करता है; क्योंकि यहां एक गलती परियोजना के अंत में तेजी से बढ़ती है। आवश्यकताओं के विश्लेषण के दो बुनियादी प्रकार हैं। कार्यात्मक आवश्यकता उस कार्य का वर्णन करती है जो सिस्टम को करना चाहिए: "ऑर्डर की पुष्टि होने पर सिस्टम को ग्राहक को ईमेल करना चाहिए।" गैर-कार्यात्मक आवश्यकता बताती है कि सिस्टम कैसा होना चाहिए: प्रदर्शन, सुरक्षा, प्रयोज्यता और पहुंच जैसे गुण। "रिपोर्ट स्क्रीन औसत लोड पर 2 सेकंड से भी कम समय में खुलनी चाहिए" एक गैर-कार्यात्मक आवश्यकता है।
एक अच्छी आवश्यकता की तीन विशेषताएं होती हैं: यह स्पष्ट है (इसकी एक ही व्याख्या है), यह मापने योग्य है (इसकी एक परीक्षण योग्य सीमा है), और यह पता लगाने योग्य है (यह स्पष्ट है कि यह किस व्यावसायिक आवश्यकता से आती है)। "सिस्टम तेज़ होना चाहिए" इनमें से किसी से भी मेल नहीं खाता; "तेज़" व्यक्तिपरक है, मापा नहीं जा सकता, परीक्षण नहीं किया जा सकता। इस स्तर पर, एआई आवश्यकताओं का मसौदा तैयार करने और अस्पष्ट शब्दों को पकड़ने में एक शक्तिशाली सहायता है; लेकिन केवल हितधारक ही निर्णय लेता है कि कौन सा व्यावसायिक नियम वास्तविक है।
उपयोगकर्ता कहानी और स्वीकृति मानदंड
आधुनिक आवश्यकताओं के लेखन में एक सामान्य प्रारूप उपयोगकर्ता की कहानी है: "एक [भूमिका] के रूप में, [उद्देश्य] के लिए, मुझे [सुविधा] चाहिए।" उदाहरण: "एक बिक्री प्रतिनिधि के रूप में, मैं मोबाइल स्क्रीन से छूट की गणना चाहता हूं ताकि मैं क्षेत्र में त्वरित उद्धरण दे सकूं।" कहानी छोटी और व्यवसाय-उन्मुख है; यह कोई तकनीकी समाधान नहीं थोपता.
प्रत्येक कहानी में स्वीकृति मानदंड होने चाहिए: परीक्षण योग्य शर्तें जिन्हें कहानी को "ठीक" मानने के लिए पूरा किया जाना चाहिए। अक्सर उपयोग किया जाने वाला पैटर्न "दिया/कब/तब" पैटर्न है: "दिया गया: ग्राहक वीआईपी सेगमेंट में है। जब: 10,000 टीएल से अधिक का ऑर्डर होता है। तब: सिस्टम 5% छूट लागू करता है।" यह पैटर्न अस्पष्टता को समाप्त करता है क्योंकि यह स्थिति और अपेक्षित परिणाम को स्पष्ट रूप से जोड़ता है।
युक्ति: कृत्रिम बुद्धिमत्ता पर उपयोगकर्ता कहानी लिखते समय, यह अवश्य कहें कि "प्रत्येक कहानी के लिए दिए गए/कब/तब प्रारूप में कम से कम 2 स्वीकृति मानदंड उत्पन्न करें।" जब मॉडल को बेंचमार्क तैयार करने के लिए मजबूर किया जाता है, तो आवश्यकता में छिपी कमियां दिखाई देने लगती हैं।
चरण दर चरण: एआई-सहायता प्राप्त आवश्यकताएँ निष्कर्षण
चरण 1 - कच्चा इनपुट एकत्र करें। कॉल लॉग, ईमेल, मौजूदा स्क्रीनशॉट, शिकायत सूचियां। जितना अधिक वास्तविक इनपुट, उतना कम निर्माण।
चरण 2 - कहानियों का पहला सेट निकालें। कृत्रिम बुद्धिमत्ता को कच्चा इनपुट दें और उससे उपयोगकर्ता कहानी ड्राफ्ट तैयार करने को कहें। यह चरण पूरी सूची नहीं है, बल्कि पहला चरण है.
चरण 3 - स्वीकृति मानदंड जोड़ें। प्रत्येक कहानी के लिए दिए गए/कब/तब मानदंड उत्पन्न करें। एक कहानी जिसके लिए मानदंड तैयार नहीं किए जा सकते, वास्तव में इसका मतलब है कि यह पर्याप्त रूप से परिभाषित नहीं है।
चरण 4 - विरोधाभासों और अंतरालों की स्कैनिंग। एआई से पूछें "क्या इन आवश्यकताओं के बीच कोई विरोधाभास, दोहराव या अपरिभाषित स्थितियाँ हैं?" पूछो और इसकी जांच कराओ. एक इंसान के रूप में परिणाम को फ़िल्टर करें।
चरण 5 - प्राथमिकता दें और पुष्टि करें। व्यावसायिक मूल्य और तात्कालिकता के आधार पर हितधारकों के साथ कहानियों को प्राथमिकता दें। प्राथमिकता वाला निर्णय व्यावसायिक इकाई का है, एआई का नहीं।
गैर-कार्यात्मक आवश्यकताओं को न भूलें
अधिकांश परियोजनाओं में क्षेत्र में कठिनाइयाँ होती हैं क्योंकि वे कार्यात्मक आवश्यकताओं को लिखते समय गैर-कार्यात्मक को भूल जाते हैं। एक रिपोर्ट "सही ढंग से" काम कर सकती है, लेकिन अगर इसे खुलने में 45 सेकंड लगते हैं, तो कोई भी इसका उपयोग नहीं करेगा। निम्न तालिका आम तौर पर नजरअंदाज किए गए गैर-कार्यात्मक आवश्यकता प्रकारों और मापने योग्य लेखन उदाहरणों को दिखाती है।
शैली
ख़राब अभिव्यक्ति
मापने योग्य अभिव्यक्ति
प्रदर्शन
"तेज़ होना चाहिए"
"क्वेरी प्रतिक्रिया <औसत लोड पर 2 सेकंड"
अभिगम्यता
"हर किसी को इसका उपयोग करने में सक्षम होना चाहिए"
"WCAG 2.1 AA अनुरूप; पूर्ण कीबोर्ड नेविगेशन"
सुरक्षा
"यह सुरक्षित होना चाहिए"
"व्यक्तिगत डेटा बाकी समय एन्क्रिप्टेड है; पहुंच भूमिका-आधारित है"
उपलब्धता
"आसान होना चाहिए"
"नया उपयोगकर्ता बिना प्रशिक्षण के 3 चरणों में ऑर्डर पूरा करता है"
उपलब्धता/निरंतरता
"दुर्घटना नहीं होनी चाहिए"
"मासिक अपटाइम ≥ 99.5%"
तीन मिनी मामले: संख्याओं द्वारा
केस 1 - एक अथाह आवश्यकता की कीमत। स्क्रीन, जिसे एक बैंक में इस आवश्यकता के साथ विकसित किया गया था कि "रिपोर्ट स्क्रीन जल्दी खुलनी चाहिए", फ़ील्ड लोड के तहत 22 सेकंड में खुल गई। डेवलपर ने सोचा कि वह अपने वातावरण में "तेज़" शब्द प्रदान कर रहा है (2 सेकंड)। यदि आवश्यकता को "पीक ऑवर में <3 सेकंड, वास्तविक थ्रूपुट" के रूप में लिखा गया होता, तो समस्या परीक्षण में पकड़ी गई होती। पुनर्विकास लागत 3 सप्ताह और मापने योग्य अतिरिक्त लागत।
केस 2 - स्वीकृति मानदंड द्वारा पकड़ा गया अंतर। एक ई-कॉमर्स परियोजना में "सिस्टम लागू छूट" कहानी के लिए स्वीकृति मानदंड लिखते समय, हितधारक ने देखा कि यदि कूपन और वीआईपी छूट के साथ विरोधाभासी छूट पर बिल्कुल भी चर्चा नहीं की गई तो क्या होगा। लाइव होने से पहले एक एकल दिए गए/कब/तब प्रश्न ने दोहरी छूट त्रुटि को रोक दिया; इस त्रुटि के कारण समान परियोजनाओं में गंभीर राजस्व हानि हुई।
केस 3 - एआई-निर्मित नियम। एक एचआर परियोजना में, एआई ने आवश्यकताओं के मसौदे में "छुट्टी अनुरोध 24 घंटों के भीतर स्वचालित रूप से स्वीकृत हो जाता है" वाक्य जोड़ा। बैठक में ऐसी किसी स्वत: मंजूरी पर चर्चा नहीं हुई; मॉडल ने एक नियम बनाया था जो "उचित" प्रतीत होता था। प्रत्येक आवश्यकता के आगे, विशेषज्ञ लिखता है "स्रोत: कौन सा साक्षात्कार/दस्तावेज़?" कॉलम जोड़कर, उन्होंने 4 बिना स्रोत वाले वाक्य हटा दिए।
कमजोर संकेत/मजबूत संकेत
कमजोर संकेत:
इस प्रोजेक्ट के लिए उपयोगकर्ता कहानियां लिखें.
शक्तिशाली संकेत:
आपकी भूमिका: आप एक एमआईएस व्यवसाय विश्लेषक हैं। नीचे साक्षात्कार नोट से उपयोगकर्ता कहानियां निकालें। नियम: - प्रारूप: "एक [भूमिका] के रूप में, [उद्देश्य] के लिए, मैं [सुविधा] चाहता हूं।" - प्रत्येक कहानी के लिए दिए गए/कब/फिर प्रारूप में कम से कम 2 स्वीकृति मानदंड लिखें। - प्रत्येक कहानी के आगे एक "स्रोत" कॉलम जोड़ें: यह किस वाक्य से आया है? - लेबल [अनिश्चित] कोई भी नियम जो नोट में स्पष्ट नहीं है; फिटिंग.- मापने योग्य गैर-कार्यात्मक आवश्यकताओं (प्रदर्शन, सुरक्षा, पहुंच) को एक अलग अनुभाग में लिखें। साक्षात्कार नोट:[पाठ]
शक्तिशाली संकेत कहानी प्रारूप, स्वीकृति मानदंड, स्रोत पता लगाने की क्षमता और गैर-कार्यात्मक आवश्यकताओं को एक साथ लागू करता है; इससे आउटपुट को नियंत्रित करना आसान हो जाता है।
चार प्रतिलिपि योग्य टेम्पलेट
1) आवश्यकताएँ स्पष्टीकरण:
नीचे दी गई आवश्यकता की समीक्षा करें. प्रत्येक कथन को चिह्नित करें जो अस्पष्ट, असंगत, या एक से अधिक व्याख्या के लिए खुला है और प्रत्येक के लिए एक स्पष्ट प्रश्न लिखें। उत्तर मत बनाओ. आवश्यकता: [पाठ]
2) विरोधाभास स्कैनिंग:
नीचे दी गई आवश्यकताओं की सूची में, वे आइटम ढूंढें जो एक-दूसरे के विपरीत हैं, दोहराव वाले हैं, या तार्किक अंतराल छोड़ते हैं। प्रत्येक निष्कर्ष को आइटम नंबर और एक-वाक्य औचित्य के साथ रिपोर्ट करें। सूची: [पाठ]
3) स्वीकृति मानदंड तैयार करना:
सीमा और अपवाद मामलों सहित, दिए गए/कब/तब प्रारूप में निम्नलिखित उपयोगकर्ता कहानी के लिए कम से कम 4 स्वीकृति मानदंड लिखें। जो भी बिंदु अस्पष्ट रह गए हों उन्हें भी सूचीबद्ध करें। कहानी: [पाठ]
4) कार्यक्षेत्र की रूपरेखा:
निम्नलिखित आवश्यकताओं के अनुसार "स्कोप में" और "स्कोप से बाहर" आइटम को दो-स्तंभ तालिका के रूप में ड्राफ़्ट करें। किसी भी आइटम के लिए लेबल [पुष्टि आवश्यक] जिसके बारे में आप अनिश्चित हैं। आवश्यकताएँ: [पाठ]
सामान्य गलतियाँ
- समाधान सोचना एक आवश्यकता है। "ड्रॉपडाउन मेनू जोड़ें" एक समाधान है, आवश्यकता नहीं। आवश्यकता कहती है "उपयोगकर्ता को परिभाषित सूची से देश का चयन करने में सक्षम होना चाहिए"; आईटी टीम समाधान डिजाइन करती है।
- गैर-कार्यात्मक को छोड़ना। बस "क्या करना है" लिखना और "कैसे करना है" (गति, सुरक्षा, पहुंच) भूल जाना सबसे आम और सबसे महंगा बचाव का रास्ता है।
- अथाह विशेषणों का प्रयोग। "तेज, आसान, सुरक्षित, उपयोगकर्ता के अनुकूल" जैसे शब्द बिना किसी सीमा के अमान्य हैं।
- एआई ने जो नियम बनाया है उस पर ध्यान नहीं दिया जा रहा है। मॉडल "उचित" जोड़ सकता है लेकिन वास्तव में बोले गए नियम नहीं; हर जरूरत के लिए संसाधन मांगें।
- एआई को प्राथमिकता देना। पहले क्या करना है यह एक व्यावसायिक मूल्य निर्णय है; बिजनेस यूनिट यह देती है.
सावधानी: आवश्यकताओं के विश्लेषण में सबसे खतरनाक वाक्य है "हर कोई यह पहले से ही जानता है"। अनकही धारणाएँ इसे दस्तावेज़ीकरण में शामिल नहीं करती हैं, इसे कभी कोड में नहीं बनाती हैं, और फ़ील्ड में उभरती हैं। एआई से पूछें "इस आवश्यकता में क्या माना गया है लेकिन क्या नहीं लिखा गया है?" इन छिपी हुई धारणाओं को दृश्यमान बनाता है।
सारांश
आवश्यकताओं का विश्लेषण परिभाषित करता है कि सिस्टम को स्पष्ट, मापने योग्य और पता लगाने योग्य तरीके से क्या करना चाहिए। कार्यात्मक आवश्यकताएँ कार्य का वर्णन करती हैं, गैर-कार्यात्मक आवश्यकताएँ गुणों का वर्णन करती हैं, और बाद वाली को अक्सर भुला दिया जाता है। उपयोगकर्ता कहानी और दिया/कब/तब स्वीकृति मानदंड शक्तिशाली उपकरण हैं जो अनिश्चितता को खत्म करते हैं। आर्टिफिशियल इंटेलिजेंस स्टोरीबोर्ड, स्वीकृति मानदंड, संघर्ष का पता लगाने और प्रश्नों को स्पष्ट करने के उत्पादन में काफी तेजी लाता है; हालाँकि, व्यवसाय नियम की शुद्धता, दायरा और प्राथमिकता निर्णय और प्रत्येक वाक्य का स्रोत मानव की जिम्मेदारी है। किसी भी ऐसी आवश्यकता को अंतिम रूप न दें जो स्रोतहीन और अथाह हो।
आवेदन कार्य
एक काल्पनिक "ऑनलाइन अपॉइंटमेंट सिस्टम" के लिए एक पैराग्राफ वाला व्यावसायिक अनुरोध लिखें (उदाहरण के लिए, "ग्राहकों को ऑनलाइन अपॉइंटमेंट लेने में सक्षम होना चाहिए, कर्मचारियों को कैलेंडर देखने में सक्षम होना चाहिए")। (1) इस अनुरोध से एक मजबूत संकेत के साथ प्रत्येक के लिए कम से कम 5 उपयोगकर्ता कहानियां और 2 स्वीकृति मानदंड बनाएं। (2) मॉडल द्वारा उत्पादित मानदंडों में कम से कम 2 छिपे हुए अंतराल का पता लगाएं (उदाहरण के लिए एक ही समय में दोहरी नियुक्ति, रद्दीकरण नियम)। (3) मापने योग्य रूप में कम से कम 3 गैर-कार्यात्मक आवश्यकताओं को शामिल करें। (4) कम से कम 3 वस्तुओं को "दायरे से बाहर" के रूप में पहचानें। (5) मॉडल द्वारा बनाए गए एक नियम को चिह्नित करें और लिखें कि आप इसकी पुष्टि कैसे करेंगे।
चेकलिस्ट
- [ ] मैंने कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं को अलग-अलग लिखा है।
- [ ] प्रत्येक आवश्यकता स्पष्ट, मापने योग्य और परीक्षण योग्य है।
- [ ] प्रत्येक कहानी में दिया/कब/तब स्वीकृति मानदंड हैं।
- [ ] मैं प्रत्येक आवश्यकता के स्रोत (बातचीत/दस्तावेज़) का पता लगा सकता हूं।
- [ ] मैंने एआई द्वारा बनाए गए संभावित नियमों को चिह्नित किया और उन्हें पुष्टि के लिए छोड़ दिया।
- [ ] मैंने व्यवसाय इकाई के साथ मिलकर प्राथमिकता तय की।