आवश्यकताएँ प्रबंधन और पता लगाने की क्षमता के लिए सबसे पूर्ण मार्गदर्शिका
एक आवश्यकता प्रबंधन उपकरण कैसे लागू करें
विषय - सूची
एक आवश्यकता प्रबंधन उपकरण कैसे लागू करें?
आवश्यकताएँ प्रबंधन उपकरण लागू करने के लिए, आप कई कदम उठा सकते हैं।
सबसे पहले, आपको टूल के हितधारकों और उपयोगकर्ताओं की पहचान करने की आवश्यकता है। इसमें परियोजना प्रबंधक, व्यापार विश्लेषक, विकासकर्ता, परीक्षक और अन्य लोग शामिल हैं जो इसका उपयोग करेंगे। आपको यह निर्धारित करने की भी आवश्यकता है कि आपके संगठन के आकार, परियोजनाओं की जटिलता और अन्य कारकों के आधार पर किस प्रकार की आवश्यकताओं की प्रबंधन प्रणाली सबसे अच्छी है।
इसके बाद, आपको यह तय करना चाहिए कि आप अपनी आवश्यकताओं की प्रबंधन प्रक्रिया के लिए किस सॉफ्टवेयर टूल या प्लेटफॉर्म का उपयोग करना चाहते हैं। आज बाजार में विश्योर जैसे कई अलग-अलग प्रकार उपलब्ध हैं। एक बार जब आप तय कर लेते हैं कि आपके संगठन की जरूरतों के लिए कौन सा सबसे अच्छा है तो सिस्टम स्थापित करने का समय आ गया है। इसमें उपयोगकर्ता खाते बनाना, विभिन्न उपयोगकर्ताओं के लिए पहुँच स्तर स्थापित करना और सॉफ़्टवेयर की उचित कार्यक्षमता सुनिश्चित करने के लिए सेटिंग्स को कॉन्फ़िगर करना शामिल हो सकता है।
एक बार आपकी आवश्यकता प्रबंधन उपकरण ठीक से स्थापित हो जाने के बाद इसका उपयोग शुरू करने का समय आ गया है! आपको हितधारकों से आवश्यकताओं को इकट्ठा करने और व्यवस्थित करने के लिए टेम्पलेट्स को परिभाषित करना चाहिए। इसके अतिरिक्त, आपको एक प्रक्रिया और नियम सेट बनाना चाहिए जो यह सुनिश्चित करता है कि प्रत्येक आवश्यकता को सही ढंग से प्रलेखित किया गया है ताकि उन्हें उसके पूरे जीवन चक्र के अनुसार ट्रैक किया जा सके। अंत में, आपको एक समीक्षा प्रक्रिया स्थापित करनी चाहिए ताकि किसी आवश्यकता के सभी परिवर्तनों या अद्यतनों को लागू करने से पहले ठीक से समीक्षा की जा सके।
आपको आवश्यकताएँ प्रबंधन उपकरण की आवश्यकता क्यों है?
यह कोई रहस्य नहीं है कि खराब आवश्यकताएं खराब गुणवत्ता वाले उत्पादों की ओर ले जाती हैं और ये परियोजनाएं अक्सर दायरे से भरी होती हैं। आवश्यकताओं के लिए दस्तावेज़-आधारित दृष्टिकोण के साथ कई चुनौतियाँ हैं, जिसमें यह तथ्य भी शामिल है कि उन्हें हमेशा बदलते सॉफ़्टवेयर विकास में अद्यतित रखना मुश्किल है। भले ही आपने उपयोगकर्ता आवश्यकताओं को इकट्ठा करने और दस्तावेजीकरण करने में एक शानदार काम किया हो, फिर भी आवश्यकताओं को प्रबंधित करने का कार्य अभी शुरू हुआ है।
कार्ल वीगर्स (स्वचालित आवश्यकता प्रबंधन पर www.processimpact.com लेख) के अनुसार एक स्वचालित आवश्यकता प्रबंधन उपकरण का उपयोग करने के कुछ प्राथमिक कारण यहां दिए गए हैं।
संस्करण और परिवर्तन प्रबंधित करें। अधिकांश प्रणालियाँ आज पुनरावृत्त (या चुस्त) फैशन में जारी की जाती हैं। इसका मतलब है कि आवश्यकताओं में रिलीज़ से जुड़े संस्करण होंगे। परिवर्तनों को ट्रैक करने में सक्षम होने और परिवर्तन और गुंजाइश रेंगने को नियंत्रित करने में परिवर्तनों के प्रभाव की पहचान करने में सक्षम होना।
आवश्यकता विशेषताओं में आवश्यकता के बारे में अतिरिक्त जानकारी संग्रहीत करें। आवश्यकता के कथन के अलावा किसी अन्य आवश्यकता के बारे में हमें और भी बहुत कुछ जानने की आवश्यकता है। उदाहरण के लिए, आवश्यकताओं की स्थिति, प्राथमिकता, किसने इसका अनुरोध किया, और परीक्षण की स्थिति। ये केवल कुछ सुझाव हैं।
आवश्यकताओं को अन्य सिस्टम तत्वों से लिंक करें। यह सुनिश्चित करने के लिए कि सभी आवश्यकताएँ उत्पाद का हिस्सा हैं, सभी आवश्यकताओं का परीक्षण किया जाता है, परिवर्तनों का मूल्यांकन किया जाता है, आदि। हमें आवश्यकताओं को अन्य सिस्टम तत्वों से जोड़ने में सक्षम होने की आवश्यकता है।
ट्रैक स्थिति। उन सभी आवश्यकताओं की सूची बनाने में सक्षम होने के बारे में सोचें जो स्वीकृत नहीं हैं, सभी आवश्यकताएं जो निचले स्तर की आवश्यकताओं से जुड़ी नहीं हैं, और सभी आवश्यकताएं जिनका परीक्षण नहीं किया गया है। इस प्रकार की जानकारी से हमें वास्तव में परियोजना की स्थिति जानने में मदद मिलती है।
आवश्यकताएँ उपसमुच्चय देखें। उन सभी उच्च-प्राथमिकता वाली आवश्यकताओं को देखने में सक्षम होने के बारे में सोचें जिनके लिए कोई परीक्षण विधि असाइन नहीं की गई है। या एक सुरक्षा कार्यालय जो केवल सुरक्षा संबंधी आवश्यकताओं की समीक्षा करना चाहता है। आवश्यकताओं को फ़िल्टर करने में सक्षम होने से केवल उन सूचनाओं को शामिल किया जा सकता है जिन्हें देखने में उपयोगकर्ता रुचि रखता है, इन आवश्यकताओं की समीक्षा करने के लिए आवश्यक समय कम कर देता है।
पहुंच नियंत्रित करें। आप यह सुनिश्चित करना चाहेंगे कि व्यापार विश्लेषक केवल उपयोगकर्ता आवश्यकताओं को ही संशोधित कर सकते हैं; सिस्टम विश्लेषक केवल सिस्टम आवश्यकताओं को संशोधित कर सकते हैं, इत्यादि। स्वीकृत होने के बाद, आवश्यकताओं तक पहुंच सीमित होनी चाहिए ताकि समीक्षा के बिना कोई और परिवर्तन न किया जा सके।
हितधारकों के साथ संवाद करें। हितधारकों को सभी संभावित परिवर्तनों के बारे में पता होना सुनिश्चित करने के लिए परिवर्तनों की अधिसूचना आवश्यक है। अधिकांश आवश्यकता प्रबंधन उपकरण स्वचालित रूप से इस प्रकार की अधिसूचना प्रदान करने में सहायता कर सकते हैं।
हममें से जिन लोगों ने आवश्यकता प्रबंधन उपकरणों का उपयोग किया है, उनके लिए यह कल्पना करना मुश्किल है कि कागज पर उस काम को वापस करने की कल्पना करना मुश्किल है। और मेरा मानना है कि हम में से कुछ ही ऐसे हैं जो उस पद्धति पर वापस जाना पसंद करेंगे। मैं व्यक्तिगत रूप से दस्तावेज़-आधारित दृष्टिकोण पर कोई आवश्यकता प्रबंधन उपकरण लूंगा। हालाँकि, यह मेरे लिए आश्चर्यजनक है कि सभी आकार के कई संगठन अपनी आवश्यकताओं को प्रबंधित करने के लिए दस्तावेज़-आधारित उपकरणों पर निर्भर रहना जारी रखते हैं। आवश्यकताओं पर नियंत्रण प्राप्त करने के लिए आवश्यकताएँ प्रबंधन उपकरण का उपयोग करना एक आवश्यक पहला कदम है।
एक आवश्यकता प्रबंधन उपकरण खरीदने से पहले...
यह कोई रहस्य नहीं है कि पेशेवर आवश्यकताएं इंजीनियरिंग समाधान आवश्यकताओं के साथ काम करते समय दक्षता में सुधार करने में मदद करते हैं। वे उन गलतियों की संख्या को कम करने में भी मदद करते हैं जो आमतौर पर विकास जीवनचक्र के बाद के चरणों में पाए जाने पर महंगा सुधार करती हैं।
इसलिए, कई कंपनियां ऐसी आवश्यकताओं के लिए इंजीनियरिंग समाधानों की तलाश कर रही हैं, लेकिन दुर्भाग्य से, वही नियम जो लगभग किसी अन्य प्रकार के सॉफ़्टवेयर टूल के लिए भी इंजीनियरिंग समाधानों की आवश्यकताओं पर लागू होता है: एक उपकरण के साथ एक मूर्ख एक मूर्ख बना रहता है ...
विश्योर रिक्वायरमेंट एएलएम प्लेटफॉर्म जैसे सर्वश्रेष्ठ-इन-क्लास आवश्यकताएं इंजीनियरिंग समाधान लगभग किसी भी प्रकार की आवश्यकताओं की इंजीनियरिंग प्रक्रिया का समर्थन करने में सक्षम होने में बहुत लचीले हैं। बेशक, हम - एक उपकरण विक्रेता के रूप में - आपको कुछ सॉफ़्टवेयर बेचकर खुश हैं लेकिन हमें विश्वास है कि यह अकेले आपकी मदद नहीं करेगा। इसके बजाय, हम आपको हमारे उत्पादों का उपयोग करने में सफल होने में मदद करना चाहते हैं।
इसलिए, एक आवश्यकता इंजीनियरिंग समाधान खरीदने से पहले कृपया सुनिश्चित करें कि आपके पास कुछ भूमिकाओं को सौंपी गई कुछ गतिविधियों के साथ परिभाषित एक उचित आवश्यकता इंजीनियरिंग प्रक्रिया है। बेशक, हम भी इस क्षेत्र में अपने अनुभव आपके साथ साझा कर सकते हैं। यदि आप अपनी प्रक्रिया की विस्तृत विशेषताओं को जानते हैं तो आपके लिए एक उचित समाधान खोजना बहुत आसान हो जाता है जो आपकी प्रक्रिया की आवश्यकताओं के अनुरूप हो।
एक आवश्यकता प्रबंधन उपकरण के सफल कार्यान्वयन के लिए 6 युक्तियाँ
कई साल पहले मैंने एक बहुत ही जटिल हथियार नियंत्रण प्रणाली पर काम करते हुए कई साल बिताए थे। जैसा कि आप कल्पना कर सकते हैं कि आवश्यकताएँ बड़ी, जटिल और अक्सर बदली हुई थीं। हमने ग्राहकों और डेवलपर्स दोनों की ओर से सबमिट किए जाने वाले उन परेशान करने वाले परिवर्तनों को प्रबंधित करने का प्रयास करने में बहुत समय बिताया। उन शुरुआती दिनों में, हमारे पास इन परिवर्तनों का आकलन करने में मदद करने के लिए कोई आवश्यकता प्रबंधन उपकरण नहीं था। हम इंटरलीफ और एक्सेल का उपयोग कर रहे थे (अब मैं दर्द की कराह सुन सकता हूं)। सब कुछ मैनुअल था, जिसमें हमारी जटिल ट्रैसेबिलिटी भी शामिल थी। हमारे पास कुछ ऐसे लोग थे जिन्होंने कुछ भी नहीं किया लेकिन ट्रैसेबिलिटी मैट्रिसेस को बनाए रखा और परिवर्तनों के प्रभाव का आकलन किया। इस समय हमारे पास केवल संचालन की अवधारणा से लेकर सिस्टम आवश्यकताएँ से लेकर सबसिस्टम आवश्यकताएँ तक का पता लगाने की क्षमता थी। मैं "केवल" कहता हूं, लेकिन उस समय केवल इस स्तर की पता लगाने की क्षमता एक बड़ी उपलब्धि थी।
जब हमारे पास पर्याप्त परिवर्तन हो गए तो हमने एक नया सिस्टम आवश्यकता दस्तावेज़ और नया सबसिस्टम आवश्यकता दस्तावेज़ जारी किया। उन गरीब ठेकेदारों को भारी सबसिस्टम आवश्यकताओं से गुजरना पड़ा और मैन्युअल रूप से यह निर्धारित करना पड़ा कि क्या बदल गया है। मैं उस समय की कल्पना नहीं कर सकता जब ठेकेदारों ने केवल यह पता लगाने की कोशिश की कि उन्हें किन परिवर्तनों के बारे में चिंतित होने की आवश्यकता है।
यह इस अपग्रेड प्रोजेक्ट के बीच में था कि ग्राहक ने पर्याप्त कहा और मेरी टीम को एक आवश्यकता प्रबंधन उपकरण का मूल्यांकन और चयन करने का काम सौंपा। इस विशेष चर्चा के लिए हमारे द्वारा चुना गया टूल महत्वपूर्ण नहीं है, लेकिन इस टूल चयन और कार्यान्वयन से हमने जो सीखा वह महत्वपूर्ण है। यहाँ कुछ सबक सीखे गए हैं।
(1) - एक भी ऐसा साधन नहीं है जो सभी को खुश करने वाला हो। हमारे पास ऐसे उपयोगकर्ता थे जो हमारे चयन को पसंद करते थे और जो हमसे हर कदम पर लड़ते थे। ग्राहक के समर्थन और परिवर्तन को लागू किए बिना इस तरह के एक बड़े कार्यक्रम पर यह संभव नहीं होगा। एक उपयोगकर्ता ने उपकरण-जनित ट्रैसेबिलिटी मैट्रिक्स के स्तंभ आकार के बारे में शिकायत की, इस तथ्य को पूरी तरह से अनदेखा करते हुए कि इसने उसे मैन्युअल प्रयास के दिनों को बचाया।
(2) - हमारी मैनुअल ट्रैसेबिलिटी बहुत साफ नहीं थी। एक बार जब हमने अपनी सभी सूचनाओं को टूल में आयात कर लिया और इसे लिंक कर दिया, तो हमें पता लगाने की क्षमता में कई अंतराल मिले। इससे भी ज्यादा परेशान करने वाली बात यह थी कि हमारे पास ऐसे लिंक थे जिनका वास्तव में कोई मतलब नहीं था। हमें अपनी ट्रैसेबिलिटी मैट्रिसेस को साफ करने के लिए बहुत काम करना पड़ा।
(एक्सएनएनएक्स) - केवल आवश्यकताओं को ट्रेस करना बहुत अच्छा था, लेकिन अब हम आवश्यकताओं को परीक्षण योजनाओं से जोड़ने के लिए उसी प्रयास का उपयोग कर सकते हैं और सबसिस्टम आवश्यकताओं को डिज़ाइन दस्तावेज़ों से लिंक करने के लिए इतनी दूर चले गए हैं कि हम समीक्षा कर सकते हैं। यह रातों-रात नहीं हुआ, बल्कि हुआ। आखिरकार, हम एक सबसिस्टम आवश्यकता से लेकर एक डिज़ाइन दस्तावेज़ तक एक कोड मॉड्यूल के लिए सिस्टम आवश्यकताओं का पता लगा सकते हैं। हमने कोड मॉड्यूल की जटिलता को निर्धारित करने के लिए एक उपकरण का भी उपयोग किया और इसका उपयोग यह निर्धारित करने में मदद के लिए किया कि परिवर्तन को लागू करना और परीक्षण करना कितना कठिन होगा।
(4) - एक आवश्यकता उपकरण से मेट्रिक्स परीक्षण गतिविधियों की पूर्णता को समझने के लिए महत्वपूर्ण हैं। हम अक्सर सोचते थे कि हम परीक्षण के साथ 50% पूर्ण हैं। आखिरकार, 50% परीक्षण पूरे हो गए। हालाँकि, हमने जो पाया वह यह था कि हम पहले सिस्टम के सबसे सरल और सबसे अधिक समझे जाने वाले भागों का परीक्षण करने के लिए प्रवृत्त थे। इसलिए भले ही हम 50% पूर्ण थे, फिर भी जो कुछ बचा था वह बहुत अधिक जोखिम वाला था। हमने आवश्यकताओं की प्राथमिकताओं और सॉफ़्टवेयर जटिलता को देखते हुए अपने परीक्षण को प्राथमिकता देना सीखा, वह जानकारी जिसे हम मैन्युअल ट्रैसेबिलिटी के माध्यम से निर्धारित नहीं कर सकते थे।
(5) - अभिभूत होना बहुत आसान था। सरल शुरुआत करें। हमें अपने महत्वाकांक्षी विचारों से पीछे हटना पड़ा और एक साधारण ट्रैसेबिलिटी मॉडल के साथ शुरुआत करनी पड़ी। जैसा कि हमने सीखा और उपकरण के साथ अधिक अनुभव प्राप्त किया, हमने अपने मॉडल में और अधिक जानकारी जोड़ी। हम यह पता लगाने के लिए लगातार अपनी प्रक्रिया का आकलन कर रहे थे कि इसे बेहतर बनाने के लिए हम और क्या कर सकते हैं।
(एक्सएनएनएक्स) - प्रशिक्षण और सलाह देने में कंजूसी न करें। हमने परियोजना पर सभी को प्रशिक्षित किया और ऐसे विशेषज्ञ बनाए जो उपयोगकर्ताओं को शुरुआती बाधाओं को दूर करने में मदद करते हैं। हमने अपने विशेषज्ञों को अपने ठेकेदारों के पास सप्ताहों के लिए भेजा ताकि उन्हें उपकरण का उपयोग करने में तेजी लाने में मदद मिल सके। हमारा अपना आंतरिक उपयोगकर्ता समूह भी था। इस तरह के प्रयास के लिए तैयार रहें।
यह मेरे लिए कितना अच्छा सीखने का अनुभव था। यदि आप अपनी आवश्यकताओं की प्रक्रिया को बेहतर बनाने के लिए इस तरह के बदलाव को शुरू करने में रुचि रखते हैं, तो Visure Solutions से संपर्क करें। हमें आपके साथ आपकी प्रक्रिया पर चर्चा करने में खुशी होगी।
इस पोस्ट को शेयर करना न भूलें!
