विज़र सॉल्यूशंस


सहायता
रजिस्टर करें
लॉग इन करें
निशुल्क आजमाइश शुरु करें

लेखन आवश्यकताओं के लिए क्या करें और क्या न करें

लेखन आवश्यकताओं के लिए क्या करें और क्या न करें

विषय - सूची

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

जबकि प्रत्येक संगठन की अलग-अलग आवश्यकताएं और पद्धतियां होती हैं, लेखन आवश्यकताओं के लिए मूलभूत सिद्धांत समान रहते हैं। इस लेख में, हम कुछ सुझाव साझा करेंगे जो आपकी आवश्यकताओं के लेखन कौशल को बढ़ाने में मदद कर सकते हैं और आपको स्पष्ट और स्पष्ट आवश्यकताएँ विनिर्देशों को लिखने में मदद कर सकते हैं।

आवश्यकताएँ विशिष्टता क्या है?

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

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

आवश्यकता प्रबंधन में "सर्वोत्तम अभ्यास" का क्या अर्थ है?

यह मेरे लिए इतना दिलचस्प है कि हर कोई "सर्वोत्तम प्रथाओं" में प्रशिक्षण के बारे में बात करता है। इस शब्द का प्रयोग अक्सर यह वर्णन करने के लिए किया जाता है कि हम किस प्रकार के परामर्श भी प्रदान कर सकते हैं। उसका वास्तव में क्या अर्थ है? मेरा मानना ​​​​है कि हम सभी ने इस मिथक में प्रवेश किया है कि सर्वोत्तम अभ्यास व्यक्तियों को प्रशिक्षण देने का आधार हो सकते हैं। सर्वोत्तम प्रथाओं को प्रशिक्षित नहीं किया जाता है, वे अनुभवी होते हैं।

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

आवश्यकताएँ लिखते समय चुनौतियाँ

आवश्यकताओं को लिखते समय लोगों को विभिन्न चुनौतियों का सामना करना पड़ता है।

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

विरोधाभासी आवश्यकताएं - जब हितधारकों की अपने व्यावसायिक लक्ष्यों के लिए अलग-अलग प्राथमिकताएं होती हैं, तो इससे ऐसी आवश्यकताएं होती हैं जो एक-दूसरे के साथ संघर्ष करती हैं। ऐसे मामलों में, एक व्यापार विश्लेषक की जिम्मेदारी सभी आवश्यकताओं को विस्तार से दस्तावेज करना है, यह पहचानना है कि कौन से अनुरोध एक-दूसरे का विरोध करते हैं, और हितधारकों को यह तय करने का अवसर देते हैं कि प्राथमिकता क्या है।

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

उपयोगकर्ता इनपुट की अनुपलब्धता - कुछ कारण अंतिम उपयोगकर्ताओं की अनुपलब्धता में योगदान कर सकते हैं, और प्रत्येक को अपने स्वयं के समाधान की आवश्यकता होती है। उदाहरण के लिए, कभी-कभी अंतिम उपयोगकर्ता अपने दैनिक कार्य में इतने व्यस्त होते हैं कि वे आवश्यकता-संग्रह गतिविधियों में भाग लेने को तैयार नहीं होते हैं।

ऐसे मामलों में, एक व्यापार विश्लेषक जो सबसे अच्छा काम कर सकता है, वह है व्यस्तताओं की संख्या और लंबाई को सीमित करना। बैठक से पहले, जितना संभव हो उतना शोध करने से चर्चा को और अधिक व्यवस्थित और सूचनात्मक बनाने में मदद मिलेगी। यह लगभग आवश्यकताओं को सत्यापन सत्र में एकत्रित करने की आवश्यकताओं को बदलने जैसा है। फोकस समूहों को परिभाषित करना और प्रत्येक समूह के लिए सबसे उपयुक्त अंतिम उपयोगकर्ताओं की पहचान करना

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

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

हितधारक इनपुट - जब हितधारक या अंतिम-उपयोगकर्ता डिजाइनरों को यह बताने की कोशिश करते हैं कि सिस्टम को क्या करना चाहिए, इसके बजाय सिस्टम को कैसे काम करना चाहिए, यह उप-इष्टतम डिजाइन को जन्म दे सकता है। इसे समाप्त करने के लिए, 'क्यों?' पूछकर प्रत्येक संभावित 'झूठी आवश्यकता' की पुष्टि करें। जब तक आप उस वास्तविक समस्या पर नहीं पहुंच जाते जिसे हल करने की आवश्यकता है।

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

इस समस्या से बचने का आदर्श तरीका है बार-बार बातचीत करना और दोतरफा बातचीत विकसित करना। आपके द्वारा खोजी गई जरूरतों का दस्तावेजीकरण करें और उन्हें विभिन्न विषय वस्तु विशेषज्ञों को समीक्षा और आलोचना के लिए प्रस्तुत करें, शब्दजाल की शब्दावली बनाएं और परिसर की दोबारा जांच करें।

10 लिखते समय क्या करें और क्या न करें आवश्यकताएं:

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

# 1 मत करो। बात "क्या" नहीं "कैसे" - ध्यान इस बात पर होना चाहिए कि सिस्टम क्या करेगा, न कि यह कैसे करता है। इसके अतिरिक्त, डिज़ाइन विषयों जैसे फ़ील्ड नाम, प्रोग्रामिंग भाषा ऑब्जेक्ट और सॉफ़्टवेयर ऑब्जेक्ट में बहुत गहराई से जाने से बचें। यदि आप स्वयं को आवश्यकताएँ विशिष्टता दस्तावेज़ में इन विषयों पर चर्चा करते हुए पाते हैं, तो एक कदम पीछे हटें - इसका अर्थ है कि आप बहुत विशिष्ट हो रहे हैं।

# 2 करो। सुराग लग सकना - परियोजना प्रबंधन में पता लगाने की क्षमता यह सुनिश्चित करने के लिए है कि परियोजना में अन्य घटकों से आवश्यकताएं जुड़ी हुई हैं। यह परियोजना प्रबंधकों, डेवलपर्स और हितधारकों को सभी दिशाओं के साथ-साथ सिस्टम के अन्य हिस्सों में शुरू से अंत तक एक आवश्यकता के पूरे जीवनचक्र का ट्रैक रखने की अनुमति देता है। यदि आप ट्रेसबिलिटी को ठीक से प्रबंधित करते हैं, तो आप उस कोड से बच सकते हैं जो किसी भी आवश्यकता ('स्ट्रे' कोड) के अनुरूप नहीं है, और सुनिश्चित करें कि प्रत्येक टेस्ट केस में कम से कम एक आवश्यकता शामिल हो। आप आवश्यकताओं को एक विशिष्ट पहचानकर्ता के साथ लेबल करके और टीम के सभी सदस्यों के लिए सुलभ केंद्रीय भंडार में उनके स्रोत के बारे में जानकारी प्रदान करके पता लगाने योग्य बना सकते हैं।

# 2 मत करो। कोई अपवाद नहीं - एक आवश्यकता में एस्केप क्लॉज नहीं होना चाहिए। उदाहरण के लिए, "सिस्टम लॉगिन प्रयासों की संख्या निर्धारित करेगा, सिवाय इसके कि जब उपयोगकर्ता ने स्पष्ट रूप से गलत उपयोगकर्ता नाम दर्ज किया हो"।

# 3 करो। संभव - सुनिश्चित करें कि उपलब्ध संसाधनों के साथ-साथ परियोजना बजट और समयरेखा व्यवहार्य है। यदि यह स्थिति आवश्यकता का समर्थन कर सकती है, तो योजना के साथ आगे बढ़ना संभव है।

# 3 मत करो। "लेट-आउट" क्लाज को ना कहें - लेकिन, सिवाय, और केवल यदि आवश्यक हो, जैसे लेट-आउट वाक्यांशों से दूर रहने का प्रयास करें।

# 4 करो। कंसिस्टेंसी (Consistency) - विस्तार का एक सुसंगत स्तर बनाए रखें। उदाहरण के लिए, उपयोगकर्ता की आवश्यकताओं के लिए, एक अंतिम-उपयोगकर्ता प्रत्येक वाक्य का विषय होना चाहिए। इसी तरह, सिस्टम आवश्यकताओं के लिए, सिस्टम प्रत्येक वाक्य का विषय होना चाहिए।

# 4 मत करो। कोई संक्षिप्ताक्षर नहीं - प्रत्येक आवश्यकता बिना किसी संक्षिप्त या शब्दजाल के एक पूर्ण वाक्य होनी चाहिए।

# 5 करो। सक्रिय आवाज - हमेशा सक्रिय आवाज में लिखें, यह सुनिश्चित कर लें कि प्रत्येक वाक्य का विषय अभिनेताओं में से एक है।

# 5 मत करो। अस्पष्ट मत बनो – जैसे अस्पष्ट शब्दों का प्रयोग न करें लगभग, आदि, और आवश्यकता दस्तावेज़ में इस तरह के और शब्द। आवश्यकताओं को इस तरह से स्पष्ट करना सुनिश्चित करें कि शामिल सभी लोग उन्हें सही ढंग से समझें। अस्पष्ट बयानों से गलत व्याख्या हो सकती है और विभिन्न हितधारकों के बीच संघर्ष हो सकता है।

# 6 करो। विषय और विधेय - प्रत्येक आवश्यकता के लिए, एक विषय (उपयोगकर्ता / प्रणाली) और एक विधेय (इच्छित परिणाम, क्रिया या स्थिति) होना चाहिए।

# 6 मत करो। अटकलों से नुकसान हो सकता है - अनुमान मत लगाओ; उन सुविधाओं की सूची न बनाएं जो प्रश्न से बाहर हैं। यह कहना कि आप सभी अप्रत्याशित विफलताओं को संभालने के लिए एक प्रणाली चाहते हैं, शुद्ध कल्पना है क्योंकि कोई भी प्रणाली कभी भी 100 प्रतिशत नहीं होगी जो आप चाहते हैं। दोहराव और विरोधाभासी बयानों से बचें।

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

# 7 मत करो। विकल्प से बचें - विचारों या विकल्पों की पेशकश न करें। आप इन्हें किसी भी कथन में देख सकते हैं जिसमें वाक्यांश शामिल हो सकते हैं, हो सकता है, कर सकता है, या चाहिए।

# 8 करो। सही बात - सुनिश्चित करें कि प्रत्येक वाक्य एक उचित विषय, क्रिया और विधेय के साथ पूर्ण और व्याकरणिक रूप से सही है।

# 8 मत करो। फ्यूचर टेंस में बात न करें - अभी तक परिभाषित आवश्यकता का उल्लेख न करें। आपका लक्ष्य दस्तावेज़ को पढ़ने के लिए यथासंभव सुखद बनाना है।

# 9 करो। फोकस - पुराने कागजों के जुगाड़, लंबे वाक्यांशों और संदर्भों को समाप्त करके फोकस स्थापित करें।

# 9 मत करो। क्या और कहाँ इस्तेमाल किया जाना चाहिए? - "होगा" का उपयोग किया जाना चाहिए जहां आवश्यकताएं बताई जा रही हैं, "विल" का उपयोग तथ्यों के बयानों का प्रतिनिधित्व करने के लिए किया जाना चाहिए; और प्राप्त किए जाने वाले लक्ष्य का प्रतिनिधित्व करने के लिए "चाहिए"।

# 10 करो। संगठित कागजी कार्रवाई चमत्कार करती है - अपने दस्तावेज़ की पठनीयता में सुधार के लिए आवश्यकताओं को एक ही स्थान पर व्यवस्थित रखें और कई स्रोतों को क्रॉस-रेफ़रिंग करने में समय बर्बाद करने से बचें।

# 10 मत करो। अज्ञात शब्दों का प्रयोग न करें - "उपयोगकर्ता के अनुकूल, बहुमुखी और मजबूत" जैसे अज्ञात शब्दों का उपयोग न करें क्योंकि परीक्षण मामलों को परिभाषित करने का प्रयास करते समय कठिनाइयाँ पैदा हो सकती हैं। ये शब्द अक्सर अलग-अलग लोगों के लिए अलग-अलग अर्थ रखते हैं।

Visure आवश्यकताएँ ALM प्लेटफ़ॉर्म

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

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

निष्कर्ष

आवश्यकताएँ विनिर्देश सॉफ्टवेयर विकास में एक महत्वपूर्ण प्रक्रिया है, लेकिन अच्छी आवश्यकताओं को लिखना चुनौतीपूर्ण हो सकता है। हमारे द्वारा प्रदान की गई 20 युक्तियों से आपको बेहतर आवश्यकताओं को लिखने में मदद मिलेगी, जिससे शामिल सभी लोगों के लिए प्रक्रिया आसान हो जाएगी। यदि आप अपनी लेखन आवश्यकताओं को अगले स्तर पर ले जाना चाहते हैं, तो Visure Requirements ALM Platform जैसे टूल का उपयोग करने पर विचार करें। अनुरोध ए निशुल्क 30- दिन परीक्षण आज देखें और देखें कि कैसे हमारा प्लेटफॉर्म आपकी आवश्यकताओं को इकट्ठा करने और प्रबंधन प्रक्रियाओं को कारगर बनाने में आपकी मदद कर सकता है।

इस पोस्ट को शेयर करना न भूलें!

चोटी

आवश्यकताओं के प्रबंधन और सत्यापन को सुव्यवस्थित करना

जुलाई 11th, 2024

सुबह 10 बजे ईएसटी | शाम 4 बजे सीईटी | सुबह 7 बजे पीएसटी

लुई अर्डुइन

लुई अर्डुइन

वरिष्ठ सलाहकार, विज़्योर सॉल्यूशंस

थॉमस डिर्श

वरिष्ठ सॉफ्टवेयर गुणवत्ता सलाहकार, रेजरकैट डेवलपमेंट GmbH

विज़्योर सॉल्यूशंस और रेज़रकैट डेवलपमेंट के साथ एक एकीकृत दृष्टिकोण TESSY

सर्वोत्तम परिणामों के लिए आवश्यकता प्रबंधन और सत्यापन को सुव्यवस्थित करने का तरीका जानें।