2009-04-29 15 views
6

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

+0

क्या आप आवश्यकता इंजीनियरिंग या उपकरण के लिए पूछ रहे हैं? –

+0

मुझे लगता है कि वह पूछ रहा है कि वास्तव में उन आवश्यकताओं को कैसे इकट्ठा करना है जो वास्तव में उनके साथ एक उत्पाद बनाने में सक्षम हैं। – kemiller2002

+0

वह पूछ रहा है कि एक बेहतर मूसटैप कैसे बनाया जाए। या 1 में # 2 क्या है) कुछ करो, 2) ???, 3) लाभ? – jmucchiello

उत्तर

7

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

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

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

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

अधिक सॉफ्टवेयर आवश्यकताओं कार्ल ई Wiegers द्वारा बारे में

ये हैं कार्ल ई Wiegers द्वारा

सॉफ्टवेयर आवश्यकताओं के 2 संस्करण: यहाँ कुछ सभ्य किताबें जहां मैं इस जानकारी के कुछ पढ़ रहे हैं सभ्य किताबें और वे कई दर्शकों के लिए एसआरएस तैयार करने से सभी विषयों के बारे में बात करते हैं, "आवश्यकता के लिए।"

1

इसे सिस्टम विश्लेषण कहा जाता है - आप जाते हैं और अपने उत्पाद के उपयोगकर्ताओं के साथ बात करते हैं।

1

मैं शायद Gathering Requirements तैयारी कर रहा मैं तो Joel On Software और 37Signals चेकआउट होगा द्वारा शुरू होगा। उनके पास आवश्यकता दस्तावेज बनाने के बारे में सभ्य जानकारी है। सॉफ्टवेयर साइट पर जोएल एक के example है।

+0

http://www.joelonsoftware.com/articles/AardvarkSpec.html – roryf

+0

लिंक के लिए धन्यवाद! – kemiller2002

1

क्लाइंट से प्राप्त आवश्यकताओं को रिकॉर्ड करने के लिए SRS document का उपयोग करें।

0
  1. लोगों से बात करें - परियोजना हितधारकों और विशेष रूप से उपयोगकर्ताओं।
  2. प्रश्न पूछें। बहुत से।
  3. अपनी चर्चाओं और निष्कर्षों को दस्तावेज करें।
  4. निष्कर्षों को सत्यापित करने के लिए प्रोटोटाइप का उपयोग करें।
0

आम तौर पर यह याद रखना महत्वपूर्ण है कि आप कई स्वामी सभी को एक बार परोस रहे हैं उपयोगी है:

  1. अंत उपयोगकर्ता
  2. प्रबंधन
  3. आपका डिजाइन पर्यावरण और जो कुछ भी सीमित करता है यह लगाता

सबसे अच्छी बात यह है कि उपरोक्त सभी

इन सभी के लिए समय बिताना है टेंस: मुझे हाल ही में पैकेज डिलीवरी कंपनी के लिए ग्राउंड अप सिस्टम से प्रोग्राम करने के लिए किराए पर लिया गया था - मुझे अंतिम उपयोगकर्ता (ड्राइवर - इसे सरल और तेज़ बनाना) प्रबंधन करना था (हम जानना चाहते थे कि सभी ने क्या किया और कब/कैसे) एक प्रतिबंधक वातावरण (एक मोबाइल स्कैनर) में काम करने के साथ-साथ

मैंने प्रबंधन के साथ बहुत समय बिताया और फिर ड्राइवरों के साथ डिलीवरी पर बाहर निकल गया। उसके बाद ही मैं वास्तव में इसे संभालने में सक्षम था।

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

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

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

  • साथ

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

     संबंधित मुद्दे