आवश्यकतांचे विश्लेषण आणि भागधारकांच्या गरजांचे विश्लेषण

नफा:

• फंक्शनल आणि नॉन-फंक्शनल आवश्यकतांमध्ये फरक करण्याची क्षमता आणि कृत्रिम बुद्धिमत्तेच्या समर्थनासह स्पष्ट, मोजण्यायोग्य आवश्यकता अभिव्यक्ती लिहिण्याची क्षमता
• इंटरव्ह्यू नोट्समधून वापरकर्ता कथा, स्वीकृती निकष आणि व्याप्ती मर्यादा काढण्यासाठी संरचित प्रॉम्प्टसह कृत्रिम बुद्धिमत्ता वापरण्याची क्षमता
• अस्पष्टता, विरोधाभास आणि गहाळ नियमांसाठी AI-व्युत्पन्न आवश्यकता तपासण्याची आणि भागधारकांसह त्यांची पुष्टी करण्याची सवय लावणे

आवश्यकतांचे विश्लेषण म्हणजे प्रणालीने काय करावे हे संपूर्ण, स्पष्ट आणि पडताळण्यायोग्य पद्धतीने परिभाषित करण्याचे कार्य आहे. हे अशा टप्प्यांपैकी एक आहे जेथे एमआयएस विशेषज्ञ सर्वात जास्त मूल्य तयार करतात; कारण येथे चूक प्रकल्पाच्या शेवटी वेगाने वाढते. आवश्यकता विश्लेषणाचे दोन मूलभूत प्रकार आहेत. कार्यात्मक आवश्यकता सिस्टमने केलेल्या कामाचे वर्णन करते: "ऑर्डरची पुष्टी केल्यावर सिस्टमने ग्राहकाला ईमेल केले पाहिजे." गैर-कार्यक्षम आवश्यकता सिस्टम कशी असावी याचे वर्णन करते: कार्यक्षमता, सुरक्षितता, उपयोगिता आणि प्रवेशयोग्यता यासारखे गुण. "रिपोर्ट स्क्रीन सरासरी लोडवर 2 सेकंदांपेक्षा कमी वेळात उघडली पाहिजे" ही गैर-कार्यक्षम आवश्यकता आहे.

चांगल्या गरजेची तीन वैशिष्ट्ये आहेत: ती स्पष्ट आहे (त्याची एकच व्याख्या आहे), ती मोजता येण्याजोगी आहे (त्याची चाचणी करण्यायोग्य थ्रेशोल्ड आहे) आणि ती शोधण्यायोग्य आहे (त्याला कोणत्या व्यवसायाची आवश्यकता आहे हे स्पष्ट आहे). "प्रणाली जलद असणे आवश्यक आहे" यापैकी काहीही पूर्ण करत नाही; "जलद" व्यक्तिनिष्ठ आहे, मोजता येत नाही, चाचणी केली जाऊ शकत नाही. या टप्प्यावर, AI आवश्यक मसुदा तयार करण्यात आणि अस्पष्ट शब्दरचना पकडण्यात एक शक्तिशाली मदत आहे; परंतु कोणता व्यवसाय नियम खरा आहे हे फक्त स्टेकहोल्डर ठरवतात.

वापरकर्ता कथा आणि स्वीकृती निकष

आधुनिक आवश्यकतांच्या लेखनातील एक सामान्य स्वरूप म्हणजे वापरकर्ता कथा: "[भूमिका] म्हणून, [उद्देश], मला [वैशिष्ट्य] हवे आहे." उदाहरण: "विक्री प्रतिनिधी म्हणून, मला मोबाइल स्क्रीनवरून सवलतीची गणना हवी आहे जेणेकरून मी फील्डमध्ये त्वरित कोट करू शकेन." कथा लहान आणि व्यवसायाभिमुख आहे; तो तांत्रिक उपाय लादत नाही.

प्रत्येक कथेला स्वीकृती निकष असणे आवश्यक आहे: कथेला "ठीक" मानले जाण्यासाठी चाचणीयोग्य अटी ज्या पूर्ण केल्या पाहिजेत. वारंवार वापरला जाणारा पॅटर्न म्हणजे "दिलेले/केव्हा/नंतर" पॅटर्न: "दिलेले: ग्राहक VIP सेगमेंटमध्ये आहे. जेव्हा: 10,000 TL पेक्षा जास्त ऑर्डर करतो. नंतर: सिस्टम 5% सूट लागू करते." हा नमुना संदिग्धता दूर करतो कारण तो स्थिती आणि अपेक्षित परिणाम स्पष्टपणे जोडतो.

टीप: कृत्रिम बुद्धिमत्तेसाठी वापरकर्ता कथा लिहिताना, "प्रत्येक कथेसाठी दिलेले/केव्हा/नंतर फॉरमॅटमध्ये किमान 2 स्वीकृती निकष तयार करा" असे म्हणण्याचे सुनिश्चित करा. जेव्हा मॉडेलला बेंचमार्क तयार करण्यास भाग पाडले जाते, तेव्हा आवश्यकतेतील लपलेले अंतर दृश्यमान होतात.

स्टेप बाय स्टेप: एआय-असिस्टेड रिक्वायरमेंट एक्सट्रॅक्शन

पायरी 1 - कच्चा इनपुट गोळा करा. कॉल लॉग, ईमेल, विद्यमान स्क्रीनशॉट, तक्रार सूची. अधिक वास्तविक इनपुट, कमी बनावट.

पायरी 2 - कथांचा पहिला संच काढा. कृत्रिम बुद्धिमत्तेला कच्चा इनपुट द्या आणि ते वापरकर्ता कथा मसुदे तयार करा. ही पायरी संपूर्ण यादी नाही तर पहिली पायरी आहे.

पायरी 3 - स्वीकृती निकष जोडा. प्रत्येक कथेसाठी दिलेले/केव्हा/नंतर निकष तयार करा. एक कथा ज्यासाठी निकष तयार केले जाऊ शकत नाहीत याचा अर्थ असा होतो की ती पुरेशी परिभाषित केलेली नाही.

पायरी 4 - विरोधाभास आणि अंतरांसाठी स्कॅनिंग. एआयला विचारा "या आवश्यकतांमध्ये काही विरोधाभास, डुप्लिकेशन्स किंवा अपरिभाषित परिस्थिती आहेत का?" विचारा आणि ते तपासा. परिणाम मानव म्हणून फिल्टर करा.

पायरी 5 - प्राधान्य द्या आणि पुष्टी करा. व्यवसाय मूल्य आणि निकड यावर आधारित भागधारकांसह कथांना प्राधान्य द्या. प्राधान्यक्रमाचा निर्णय व्यवसाय युनिटचा आहे, एआयचा नाही.

नॉन-फंक्शनल आवश्यकता विसरू नका

बहुतेक प्रकल्पांना क्षेत्रात अडचणी येतात कारण ते कार्यात्मक आवश्यकता लिहिताना गैर-कार्यात्मक विसरतात. अहवाल "योग्यरित्या" कार्य करू शकतो, परंतु तो उघडण्यास 45 सेकंद लागल्यास, कोणीही त्याचा वापर करणार नाही. खालील तक्त्यामध्ये सामान्यतः दुर्लक्षित न केलेले कार्यक्षम आवश्यकता प्रकार आणि मोजता येण्याजोगे लेखन उदाहरणे दाखवली आहेत.

शैली

वाईट अभिव्यक्ती

मोजण्यायोग्य अभिव्यक्ती

कामगिरी

"जलद असणे आवश्यक आहे"

"सरासरी लोडवर प्रश्न प्रतिसाद < 2 सेकंद"

प्रवेशयोग्यता

"प्रत्येकाने ते वापरण्यास सक्षम असावे"

"WCAG 2.1 AA अनुरूप; संपूर्ण कीबोर्ड नेव्हिगेशन"

सुरक्षा

"ते सुरक्षित असावे"

"वैयक्तिक डेटा विश्रांतीवर कूटबद्ध केला आहे; प्रवेश भूमिका-आधारित आहे"

उपलब्धता

"सोपे असावे"

"नवीन वापरकर्ता प्रशिक्षणाशिवाय 3 चरणांमध्ये ऑर्डर पूर्ण करतो"

उपलब्धता/सातत्य

"क्रॅश होऊ नये"

"मासिक अपटाइम ≥ 99.5%"

तीन मिनी प्रकरणे: संख्यांनुसार

केस 1 - मोजता न येणाऱ्या गरजेची किंमत. "रिपोर्ट स्क्रीन त्वरीत उघडली पाहिजे" या आवश्यकतेसह बँकेत विकसित केलेली स्क्रीन फील्ड लोड अंतर्गत 22 सेकंदात उघडली. विकासकाला वाटले की तो त्याच्या वातावरणात (2 सेकंद) "जलद" शब्द देत आहे. जर आवश्यकता "<3 सेकंद पीक अवर, वास्तविक थ्रूपुट" असे लिहिले असते, तर समस्या चाचणीमध्ये पकडली गेली असती. पुनर्विकासाचा खर्च 3 आठवडे आणि मोजता येण्याजोगा अतिरिक्त खर्च.

प्रकरण 2 - स्वीकृती निकषांद्वारे कॅप्चर केलेले अंतर. ई-कॉमर्स प्रकल्पामध्ये "सिस्टम लागू सूट" या कथेसाठी स्वीकृती निकष लिहिताना, भागधारकाच्या लक्षात आले की सवलत कूपन आणि व्हीआयपी सवलतींशी विरोधाभासी असल्यास काय होईल यावर अजिबात चर्चा झाली नाही. एकल दिलेले/केव्हा/नंतर प्रश्नाने गो-लाइव्ह करण्यापूर्वी दुहेरी सूट त्रुटी टाळली; या त्रुटीमुळे तत्सम प्रकल्पांमध्ये महसूलाचे गंभीर नुकसान झाले.

केस 3 — AI-निर्मित नियम. एचआर प्रकल्पामध्ये, एआयने आवश्यकतांच्या मसुद्यात “रजेची विनंती आपोआप 24 तासांच्या आत मंजूर केली जाते” हे वाक्य जोडले. अशा कोणत्याही आपोआप मंजुरीबाबत बैठकीत चर्चा झाली नाही; मॉडेलने "वाजवी" वाटणारा नियम बनवला होता. प्रत्येक आवश्यकतेच्या पुढे, तज्ञ लिहितात "स्रोत: कोणती मुलाखत/दस्तऐवज?" स्तंभ जोडून, ​​त्याने 4 अनसोर्स वाक्ये काढून टाकली.

कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट

कमकुवत प्रॉम्प्ट:

या प्रकल्पासाठी वापरकर्ता कथा लिहा.

शक्तिशाली सूचना:

तुमची भूमिका: तुम्ही एक MIS व्यवसाय विश्लेषक आहात.खालील मुलाखतीतून वापरकर्त्याच्या कथा काढा.नियम:- स्वरूप: “एक [भूमिका] म्हणून, [उद्देश], मला [वैशिष्ट्य] हवे आहे.”- प्रत्येक कथेसाठी किमान 2 स्वीकृती निकष दिलेल्या/केव्हा/नंतर फॉरमॅटमध्ये लिहा.- प्रत्येक कथेच्या पुढील वाक्यात “स्रोत” जोडा: प्रत्येक कथेतून कोणते वाक्य आले? [अनिश्चित] नोटमध्ये स्पष्ट नसलेला कोणताही नियम; फिटिंग.- मोजता येण्याजोग्या नॉन-फंक्शनल आवश्यकता (कामगिरी, सुरक्षा, प्रवेशयोग्यता) वेगळ्या विभागात लिहा. मुलाखत टीप:[मजकूर]

शक्तिशाली प्रॉम्प्ट कथेचे स्वरूप, स्वीकृती निकष, स्त्रोत शोधण्यायोग्यता आणि गैर-कार्यक्षम आवश्यकता एकाच वेळी लागू करते; यामुळे आउटपुट नियंत्रित करणे सोपे होते.

चार कॉपी करण्यायोग्य टेम्पलेट्स

1) आवश्यकता स्पष्टीकरण:

खालील आवश्यकतांचे पुनरावलोकन करा. अस्पष्ट, अतुलनीय किंवा एकापेक्षा जास्त अर्थ लावणारे प्रत्येक विधान चिन्हांकित करा आणि प्रत्येकासाठी एक स्पष्टीकरण प्रश्न लिहा. उत्तर तयार करू नका. आवश्यकता: [मजकूर]

2) विरोधाभास स्कॅनिंग:

खालील आवश्यकतांच्या सूचीमध्ये, एकमेकांशी विरोधाभास करणारे, पुनरावृत्ती करणारे किंवा तार्किक अंतर सोडणारे आयटम शोधा. आयटम क्रमांक आणि एका वाक्याचे औचित्य असलेल्या प्रत्येक शोधाचा अहवाल द्या. सूची: [मजकूर]

3) स्वीकृती निकष तयार करणे:

खालील वापरकर्ता कथेसाठी किमान 4 स्वीकृती निकष लिहा, मर्यादा आणि अपवाद प्रकरणांसह, दिलेले/केव्हा/नंतर फॉरमॅटमध्ये. तसेच अस्पष्ट राहिलेल्या कोणत्याही मुद्यांची यादी करा. कथा: [मजकूर]

4) व्याप्ती बाह्यरेखा:

खालील आवश्यकतांनुसार दोन-स्तंभ सारणी म्हणून "कार्यक्षेत्रात" आणि "कार्यक्षेत्राबाहेर" आयटमचा मसुदा तयार करा. तुम्हाला खात्री नसलेल्या कोणत्याही आयटमसाठी [पुष्टीकरण आवश्यक] लेबल करा. आवश्यकता: [मजकूर]

सामान्य चुका

• उपाय विचार करणे गरजेचे आहे. "ड्रॉपडाउन मेनू जोडा" हा उपाय आहे, आवश्यकता नाही. आवश्यकता म्हणते "वापरकर्त्याने परिभाषित सूचीमधून देश निवडण्यास सक्षम असणे आवश्यक आहे"; आयटी टीम सोल्यूशन डिझाइन करते.
• नॉन-फंक्शनल वगळणे. फक्त "काय करावे" लिहून ठेवणे आणि "कसे असावे" (वेग, सुरक्षितता, प्रवेशयोग्यता) विसरणे ही सर्वात सामान्य आणि सर्वात महाग पळवाट आहे.
• अमाप विशेषण वापरणे. "जलद, सोपे, सुरक्षित, वापरकर्ता-अनुकूल" सारखे शब्द थ्रेशोल्डशिवाय अवैध आहेत.
• एआयने बनवलेला नियम लक्षात न घेणे. मॉडेल "वाजवी" जोडू शकते परंतु प्रत्यक्षात बोललेले नियम नाही; प्रत्येक गरजेसाठी संसाधने विचारा.
• AI ला प्राधान्य देणे. प्रथम काय करावे हे व्यावसायिक मूल्याचा निर्णय आहे; व्यवसाय युनिट हे देते.

खबरदारी: आवश्यकता विश्लेषणातील सर्वात धोकादायक वाक्य आहे "प्रत्येकाला हे आधीच माहित आहे". न बोललेले गृहितक ते दस्तऐवजीकरणात बनवत नाहीत, ते कोडमध्ये बनवत नाहीत आणि क्षेत्रात उदयास येत नाहीत. AI ला विचारा "या गरजेमध्ये काय गृहित धरले आहे परंतु लिहिलेले नाही?" या लपलेल्या गृहितकांना दृश्यमान करते.

सारांशात

आवश्यकतांचे विश्लेषण स्पष्ट, मोजता येण्याजोगे आणि शोधण्यायोग्य मार्गाने सिस्टमने काय करावे हे परिभाषित करते. कार्यात्मक आवश्यकता नोकरीचे वर्णन करतात, गैर-कार्यात्मक आवश्यकता गुणांचे वर्णन करतात आणि नंतरचे अनेकदा विसरले जातात. वापरकर्ता कथा आणि दिलेले/केव्हा/नंतर स्वीकृती निकष ही अनिश्चितता दूर करणारी शक्तिशाली साधने आहेत. आर्टिफिशियल इंटेलिजन्स स्टोरीबोर्ड, स्वीकृती निकष, संघर्ष शोधणे आणि स्पष्टीकरण प्रश्नांच्या निर्मितीला लक्षणीयरीत्या गती देते; तथापि, व्यवसाय नियम, व्याप्ती आणि प्राधान्य निर्णयाची शुद्धता आणि प्रत्येक वाक्याचा स्रोत ही मानवाची जबाबदारी आहे. स्रोत नसलेली आणि अथांग अशी कोणतीही आवश्यकता अंतिम करू नका.

अर्ज कार्य

काल्पनिक "ऑनलाइन अपॉइंटमेंट सिस्टम" साठी एक-परिच्छेद व्यवसाय विनंती लिहा (उदा., "ग्राहक ऑनलाइन भेटी घेण्यास सक्षम असावेत, कर्मचारी कॅलेंडर पाहण्यास सक्षम असावे"). (1) या विनंतीच्या जोरदार प्रॉम्प्टसह प्रत्येकासाठी किमान 5 वापरकर्ता कथा आणि 2 स्वीकृती निकष तयार करा. (२) मॉडेलने तयार केलेल्या निकषांमध्ये कमीत कमी २ लपलेले अंतर शोधा (उदा. एकाच वेळी दुहेरी भेट, रद्द करण्याचा नियम). (3) मोजता येण्याजोग्या स्वरूपात किमान 3 गैर-कार्यक्षम आवश्यकता समाविष्ट करा. (4) किमान 3 आयटम "कार्यक्षेत्राबाहेर" म्हणून ओळखा. (५) मॉडेलने बनवलेला नियम चिन्हांकित करा आणि तुम्ही त्याची पुष्टी कशी कराल ते लिहा.

चेकलिस्ट

• [ ] मी कार्यात्मक आणि गैर-कार्यात्मक आवश्यकता स्वतंत्रपणे लिहिले.
• [] प्रत्येक आवश्यकता स्पष्ट, मोजण्यायोग्य आणि चाचणी करण्यायोग्य आहे.
• [] प्रत्येक कथेला दिलेले/केव्हा/नंतर स्वीकृतीचे निकष आहेत.
• मी प्रत्येक गरजेचा स्त्रोत (संभाषण/दस्तऐवज) शोधू शकतो.
• [] AI ने बनवलेले संभाव्य नियम मी चिन्हांकित केले आणि ते पुष्टीकरणासाठी सोडले.
• [ ] मी व्यवसाय युनिटसह प्राधान्यक्रम केले.