आवश्यकताओं के दस्तावेज़ बनाने का उचित तरीका क्या है?

24

अभी मेरे पर्यवेक्षक बगट्रैकिंग सॉफ़्टवेयर का उपयोग करके मेरे लिए आवश्यकता प्रलेखन / चश्मा बना रहा है। यह मेरे लिए एक भयानक विचार की तरह लगता है, सभी आवश्यकताएं इन छोटे टिकटों पर हैं और आवश्यकताओं को प्राप्त करने के लिए मुझे इस गूंगे वेबफॉर्म पर क्लिक करना होगा। आवश्यकताओं / सॉफ्टवेयर स्पेक्स के लिए एक साॅन सॉफ्टवेयर सॉल्यूशन क्या है?

स्पष्ट होने के लिए, मैं इस बड़े सॉफ़्टवेयर घटक का निर्माण कुछ विशेषताओं के साथ कर रहा हूं और ये सुविधाएँ इस बगट्रैकिंग सॉफ़्टवेयर में स्थापित की जा रही हैं।

design requirements issue-tracking

— पैट्रिक
स्रोत

18

मैं इस बात से हैरान हूं कि अब तक किसी ने भी ट्रैकिंग आवश्यकताओं के लिए विकी के इस्तेमाल की सिफारिश नहीं की है ।

मैंने पाया है कि यह लगभग पूर्ण प्रणाली है, क्योंकि:

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

पसंद को देखते हुए, मैं इन दिनों लगभग हमेशा विकी पद्धति का चयन करता हूं, यह पुराने जमाने के वर्ड डॉक्यूमेंट्स की तुलना में वास्तव में काफी दर्द रहित है या सभी को बग ट्रैकर में बदलने की कोशिश कर रहा है।

— Aaronaught
स्रोत

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

— टिम विस्क्रॉफ्ट

बिल्कुल, एक विकी बग ट्रैकिंग सिस्टम के लिए एक प्रतिस्थापन नहीं है, यह पूरक है। विकी पर परियोजना की योजना और सहयोग सबसे अच्छा है; मुद्दों को अभी भी एक IMS या प्राथमिकता कतार पर नज़र रखने की आवश्यकता है।

— हारून को

6

मैं हमेशा अपने एसआरआर दस्तावेज़ के लिए टेम्पलेट के रूप में IEEE Std 830-1998 (सॉफ्टवेयर आवश्यकताओं के लिए IEEE अनुशंसित अभ्यास) का उपयोग करता हूं। Http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998-desc.html देखें

अंतिम SRS दस्तावेज़ स्वयं आमतौर पर एक OpenOffice.org दस्तावेज़ है, लेकिन आमतौर पर कई घटक भाग होते हैं जो इसमें जाते हैं, जिसमें स्प्रेडशीट और आरेख शामिल हैं।

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

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

— अन्य
स्रोत

5

आवश्यकता प्रबंधन के लिए बग-ट्रैकर का उपयोग करने से कंपनी के भीतर सहयोग और संचार की कमी को छिपाने की प्रवृत्ति होती है ।

किसी विशेष विधि पर निर्णय पारित किए बिना:

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

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

निश्चित रूप से उन्होंने ऐसा किया है:

उनकी अपनी योग्यता
परियोजना में उनकी हिस्सेदारी है
अन्य आवश्यकताओं के साथ संघर्ष
आवश्यकताओं में अंतराल
लागत
किसी भी तकनीकी विचार
आदि।

— azheglov
स्रोत

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

— जॉन मैकइंटायर

किसी भी संचार टूटना एक प्रक्रिया समस्या का लक्षण नहीं होगा? (ईमानदारी का इरादा)

— जॉन मैकइंटायर

@ जॉनमैकइंटायर (1): परिणाम सहयोग के बजाय पिंग-पोंग है। असाइनमेंट हमेशा सही व्यक्ति नहीं होता है, दुर्लभ मुद्दों को केवल एक व्यक्ति द्वारा हल किया जा सकता है; जहाँ अधिक लोगों की आवश्यकता होती है, असाइन करने वाले को शायद ही कभी यह निर्देश देने का अधिकार होता है कि वे क्या करें, शायद ही कभी सभी निर्भरताएँ देखें (आवश्यकताएँ शायद ही कभी स्वतंत्र हों); खोए हुए स्व-संगठन के लाभ हैं, आरओआई द्वारा प्राथमिकता या देरी की लागत, आदि

— अज़ेगलोव

@ जॉनमैकइंटायर (2): संचार का टूटना निश्चित रूप से एक संकेत है कि उनकी प्रक्रिया काम नहीं कर रही है या उनके पास कोई प्रक्रिया नहीं है या कि उनके पास अपनी कंपनी में एक स्वस्थ संचार और सहयोग संस्कृति नहीं है। मेरी स्थिति यह है कि उन्हें उन मूल कारणों का पता लगाना चाहिए।

— अज़ेगलोव

@asheglov - मुझे लगता है कि यह एक मुद्दा हो सकता है अगर असाइनमेंट कार्यान्वयनकर्ता है और किसी को फिर से असाइन करने या बात करने की अनुमति नहीं है। लेकिन मेरी स्थिति यह है कि उपकरण नहीं है, और यह सबसे अच्छा उपकरण के साथ ऐसा नहीं होगा?

— जॉन मैकइंटायर

2

मेरा मानना है कि "वर्ड" दस्तावेज निम्नलिखित कारणों से आवश्यकताओं के लिए जाने का गलत तरीका है:

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

मेरे पास ऐसा कोई वैकल्पिक सुझाव नहीं है जिसका मुझे अनुभव है, लेकिन मैंने विकल्प के रूप में पायथन के पुनर्संरचित पाठ या मार्कडाउन के बारे में सोचा है।

— ब्रूस एडिगर
स्रोत

1

मुझे लगता है कि इनमें से अधिकांश तर्क FUD की तरह लग रहे हैं। शब्द सबसे अच्छा विकल्प नहीं हो सकता है, लेकिन यह उतना बुरा नहीं है: 1. इसमें परिवर्तनों को ट्रैक करने और स्वीकार / अस्वीकार करने के लिए काफी अच्छा संशोधन / सहयोग विशेषताएं हैं, जो किसी भी vcs + diff टूल की तुलना में अधिक उपयोगकर्ता के अनुकूल हैं। 2. 2007 की रिबन UI के बाद से शैलियाँ अधिक प्रमुख हैं। यह समझाते हुए कि शैलियों का उपयोग क्यों किया जाना चाहिए, शायद एक पूरे नए सॉफ़्टवेयर की व्याख्या करना आसान है। 3. नवीनतम शब्द 16 साल पहले बनाई गई वर्ड 97 फ़ाइलों को पढ़ / सहेज सकता है। Word 2003 संगतता पैक का उपयोग करके 2010 फ़ाइलों को पढ़ / सहेज सकता है। मैं ४. और ५ से सहमत हूं। हालांकि पीडीएफ ऑनलाइन देखने का विकल्प हो सकता है।

— kapex 20

@kapep - मेरे तर्क शास्त्रीय "डर, अनिश्चितता और संदेह" की भावना में FUD नहीं हैं, शायद आप कुछ अलग तरीके से "FUD" का उपयोग करते हैं। मेरे हर तर्क का जवाब दिया जा सकता है। उदाहरण के लिए, आप कह सकते हैं "नियंत्रण-शिफ्ट- @ पर" सम्मिलित करें "मेनू पर एक अन्य डॉक्टर के खिलाफ वर्तमान दस्तावेज़ का एक लाइन-बाय-लाइन अंतर प्राप्त करने के लिए"। यह नहीं किया जा सकता है, क्योंकि आपने जो भी पेशकश की थी वह एक जवाबी राय थी। Microsoft के पास दस्तावेज़ स्वरूपों को छोड़ने का इतिहास है, या कम से कम इसे महंगा बनाने या पुराने प्रारूपों का उपयोग करने में मुश्किल है, जो उन्नयन की बिक्री को बढ़ाता है, मुझे लगता है।

— ब्रूस एडिगर

ठीक है, मुझे सही करने के लिए मिला है, केवल 3. एक FUD तर्क लगता है जो अक्सर इस्तेमाल किया जाता है जब यह मालिकाना होने के लिए शब्द / डॉक्टर को कोसने की बात आती है। सुनिश्चित करें कि Microsoft ने स्वरूपों को छोड़ दिया है - लेकिन डॉक फाइलें बहुत लंबे समय से हैं, इसलिए 'जल्द या बाद में' केवल पिछली शताब्दी से पुरातन संस्करणों पर लागू होती है, अगर वे> 2016 में समर्थन छोड़ने का निर्णय लेते हैं या जब भी अगला शब्द जारी किया जाएगा। मैं यह भी बताना चाहता था कि दस्तावेजों को "अलग" करने का एक आसान तरीका है। बेशक यह लाइन-दर-पंक्ति की तुलना नहीं कर रहा है, जो गैर-लाइन-आधारित प्रारूप में बहुत अधिक समझ में नहीं आएगा। यह अधिक इनलाइन की तरह यहाँ एसई पर अलग है।

— kapex

2

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

हम विभिन्न pdf, Excel या Visio फ़ाइलों का भी उपयोग कर सकते हैं। प्रोजेक्ट के लिए वे सभी SharePoint से एकत्रित और संपादित किए जाते हैं, इसलिए यदि आवश्यक हो तो हम पहले के संस्करण देख सकते हैं।

— HLGEM
स्रोत

1

मैं एक उत्पाद बैकलॉग (प्रति प्रोजेक्ट या उत्पाद) रखता हूं जिसमें उपयोगकर्ता कहानियां शामिल हैं । वे बग ट्रैकिंग सॉफ़्टवेयर में संग्रहीत किए जा सकते हैं जैसे आप उपयोग करते हैं। मैं personnaly का उपयोग एक्सेल बैकलॉग और के लिए Trac स्प्रिंट बैकलॉग (आप शायद उस उपकरण की तरह एक उपकरण का उपयोग) के लिए।

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

छोटी उपयोगकर्ता कहानियों को प्रबंधित करना आसान है (अनुमान सहित)

मुझे वर्ड डॉक्यूमेंट पसंद है क्योंकि यह मुझे लिंक, फॉर्मेट टेक्स्ट, टेबल, स्क्रीनशॉट और बहुत कुछ डालने की अनुमति देता है और हर कोई इसे पढ़ सकता है।

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

1

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

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

जिज्ञासा से बाहर, इसके बारे में ऐसा क्या है जो आपको पसंद नहीं है?

संपादित करें: एक चेतावनी; बग ट्रैकिंग सॉफ्टवेयर को रीब्रांड करने के लिए अपने प्रबंधक को बताएं। अन्यथा इसमें सब कुछ बग माना जाता है। मुझे अपने अंतिम क्लाइंट में यह राजनीतिक समस्या थी, जहां मैंने बग ट्रैकर में कार्य किए। अच्छा नही।

— जॉन मैकइंटायर
स्रोत

1

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

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

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

इस सामान को एक बड़े दस्तावेज़ के बजाय डेटाबेस रिकॉर्ड में रखने के बड़े फायदे हैं। एक ही समय में कई प्रोग्रामर आवश्यकताओं पर काम कर सकते हैं। अलग-अलग रिकॉर्ड लॉक किए जाते हैं, ताकि एक समय में केवल एक ही व्यक्ति संपादित कर सके, लेकिन उन्हें खोला और पढ़ा जा सकता है जबकि कोई अन्य संपादन कर रहा है। हालांकि सबसे बड़ा फायदा यह है कि यह दोनों की आवश्यकताओं, और कैसे लागू किया गया था के बारे में नोटों के दस्तावेज़ों को खोजना आसान बनाता है। अब हमारे पास 25,000 से अधिक आवश्यकताएं हैं, और हम सभी आवश्यकताओं को सभी क्षेत्रों में विशिष्ट शब्दों के साथ, या परिभाषा, या नोट्स, या जो भी हो, 10 सेकंड के भीतर आसानी से पा सकते हैं। (कोशिश करें कि 6+ साल के वर्ड डॉक्यूमेंट्स के साथ।)

मैं देख सकता हूं कि लोग यह क्यों कह सकते हैं कि "बग ट्रैकर" में आवश्यकताओं को करना एक बुरा विचार है, लेकिन मेरा अनुमान है कि टूल बेकार है, इसलिए नहीं कि खोज योग्य डेटाबेस में आवश्यकताओं को रखना एक बुरा विचार है।

— SESummers
स्रोत

1

उपलब्ध व्यावसायिक आवश्यकताओं पर नज़र रखने वाले सॉफ़्टवेयर हैं, जैसे डीओओआरएस।

— एम। डडले

1

मैंने एक बार http://www.pivotaltracker.com/ का उपयोग किया था, लेकिन मेरी वर्तमान कंपनी में हम उपयोग कर रहे हैं। मुख्य विनिर्देश स्रोत और प्रकाशस्तंभ के रूप में संयुक्त रूप से विशलिस्ट और ट्रैकिंग जारी करना। मेरे लिए यह मुश्किल है कि टीम के अन्य लोगों को किसी अन्य उपकरण का उपयोग करना शुरू करें जब वे वर्ड के लिए बहुत अधिक उपयोग किए जाते हैं।

— जूलिया के सजोपा
स्रोत

0

यदि आप चुस्त कार्यप्रणाली का अनुसरण कर सकते हैं, तो निम्नलिखित लिंक एक अच्छा चुस्त परियोजना प्रबंधन उपकरण चुनने में आपका मार्गदर्शन कर सकते हैं:

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

सौभाग्य!

— karthiks
स्रोत