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