प्रश्न "क्या?" कहाँ? कब? ”कार्यात्मक आवश्यकताओं में

एक एकीकरण प्रणाली के लिए कार्यात्मक आवश्यकताओं पर एक नज़र

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

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

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

क्या?

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

कहाँ?

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

कब?

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

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

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

पुनश्च
और, हां, जब कोई एफटी लिखता है, तो मत भूलो - हर बार जब एक प्रोग्रामर एक बेकार दस्तावेज प्राप्त करता है, तो वह दर्द से एक छोटे सफेद खरगोश को मारता है!