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