असली विश्लेषक कैसे बनें? भाग 2. आवश्यकताओं को पहचानें

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

आवश्यकताओं को बनाने या विकसित करने के चरण को सशर्त रूप से 4 चरणों में विभाजित किया जा सकता है।

1. आवश्यकताओं की पहचान (सूचना का संग्रह)।
2. आवश्यकताओं का विश्लेषण।
3. आवश्यकताओं की विशिष्टता (प्रलेखन)।
4. आवश्यकताओं का सत्यापन।

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



आवश्यकताओं की पहचान सबसे कठिन, महत्वपूर्ण, त्रुटि प्रवणता है और इसके लिए सॉफ्टवेयर विकास के गहन संचार चरण की आवश्यकता होती है।
आवश्यकताओं की पहचान एक रचनात्मक प्रक्रिया है, और प्रत्येक एक परिणाम प्राप्त करने के लिए अपने स्वयं के उपकरणों का उपयोग करता है, अर्थात। आवश्यकताओं। मेरे सामान में ऐसे तरीके हैं जिन्हें मैं "क्लासिक" कहता हूं, अर्थात् ये चालें हैं जो 90% मामलों में काम करती हैं। आवश्यकताओं की पहचान के लिए पारंपरिक तरीकों में साक्षात्कार और प्रश्नावली का उपयोग, अवलोकन और व्यावसायिक दस्तावेजों का अध्ययन शामिल है। ये सरल और किफायती तरीके हैं। मुझे आशा है कि अनुभवी हब्र्यूज़र्स उनकी सूची के पूरक हैं।

उपयोगकर्ताओं को समूहों में विभाजित करना

व्यक्तिगत उपयोगकर्ताओं की आवश्यकताओं की दृष्टि न खोने के लिए, आपको यह करना होगा:

1. विभिन्न विशेषताओं के अनुसार उपयोगकर्ताओं को वर्गीकृत करने का प्रयास करें। उदाहरण के लिए, सॉफ्टवेयर के साथ काम की आवृत्ति, उपयोग किए जाने वाले कार्य, विशेषाधिकारों और कौशल का स्तर।
2. प्रत्येक उपयोगकर्ता वर्ग में एक सक्रिय उपयोगकर्ता का चयन करें। यह व्यक्ति उपयोगकर्ताओं के एक निश्चित वर्ग के हितों का प्रतिनिधित्व करेगा, और उनकी ओर से निर्णय लेगा।

IMHO: उन लोगों को न चुनें, जो बहुत सी बातें करते हैं, लेकिन वे जो सार रूप में बोलते हैं।

उत्पाद आवश्यकताओं का पता लगाने के लिए उपयोगकर्ताओं के साथ काम करें

1. पूछताछ / साक्षात्कार

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

2. अवलोकन

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

3. संयुक्त सेमिनार आयोजित करना

आवश्यकताओं की पहचान करने पर सहयोगात्मक कार्यशालाएँ, जहाँ विश्लेषक और उपयोगकर्ता मिलकर काम करते हैं, उपयोगकर्ताओं की आवश्यकताओं की पहचान करने और आवश्यकताओं की रूपरेखा बनाने का एक शानदार तरीका है।
मुख्य बात:

1. वांछित परिणाम प्राप्त करने के लिए आपको इस तरह से संगोष्ठी का नेतृत्व करना चाहिए।
2. अग्रिम में विचार करें कि इंटरैक्शन को सबसे प्रभावी ढंग से कैसे व्यवस्थित किया जाए।
3. सेमिनार में सभी प्रतिभागियों को शामिल करना आवश्यक है।

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

नए विचारों की खोज के लिए कार्य प्रणाली या एक समान प्रणाली की समस्याओं पर रिपोर्ट का अध्ययन

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

परियोजनाओं के लिए पुन: उपयोग की आवश्यकताएं

यदि ग्राहक द्वारा आवश्यक कार्यक्षमता पहले से ही किसी अन्य उत्पाद में लागू की गई है, तो ग्राहक को मौजूदा घटकों का उपयोग करने के लिए अपनी आवश्यकताओं को संशोधित करने के लिए लचीलापन प्रदान करें।

कैसे समझें कि आवश्यकताओं का संग्रह पूरा हो गया है?

कोई विशिष्ट संकेत नहीं हैं जो दर्शाता है कि आवश्यकताओं की पहचान पूरी हो गई है। आवश्यकताओं की पहचान करना पूरी तरह से असंभव है, हालांकि, निम्नलिखित संकेत आपको बताएंगे कि जानकारी के स्रोत लगभग समाप्त हो गए हैं:

1. उपयोगकर्ता अब नए उपयोग के मामलों के साथ नहीं आ सकते हैं।
2. उपयोगकर्ता नए उपयोग के मामलों की पेशकश करते हैं, लेकिन आपने पहले से ही अन्य उपयोग के मामलों से संबंधित कार्यात्मक आवश्यकताओं को घटा दिया है।
3. उपयोगकर्ता उन समस्याओं का वर्णन करते हैं जो पहले से ही चर्चा की गई हैं;
4. प्रस्तावित नई सुविधाएँ परियोजना के दायरे से परे हैं;
5. उपयोगकर्ताओं को कुछ समय बाद यह महसूस करने के लिए समझ में आता है कि सुविधाएँ प्रदान करते हैं।

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

संदर्भ:

कार्ल विगर्स "सॉफ्टवेयर आवश्यकताओं का विकास"