बिजनेस इंटेलिजेंस: "सिस्टम आवश्यकताओं की सूची कैसे लिखें?", एलिस्टेयर कोबर्न, समीक्षा भाग 1

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


शायद इस पुस्तक को अभी भी मूल में पढ़ा जाना चाहिए, क्योंकि रूसी अनुवादों में यह मेरे लिए अक्सर अस्पष्ट था कि वे किस बारे में बात कर रहे थे।

मुख्य अवधारणाएँ:

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

सामान्य नियम

शायद उन्हें पूरी तरह से उद्धृत करने के लिए इसके लायक है:

1. सिस्टम विवरण पठनीय होना चाहिए;
2. आपको हमेशा एक सामान्य अवधारणा के साथ शुरुआत करने की जरूरत है, और आत्महत्या करने के लिए जाएं,

प्रत्येक चरण के लिए:

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

डेटा विवरण के लिए:

विवरण में दर्ज करें मामले के मामले में केवल इसी के अनुरूप विस्तार का उपयोग करें।
विस्तार स्तर 1: डेटा नाम
विस्तार स्तर 2: डेटा फ़ील्ड नाम के साथ संबद्ध है
विवरण 3 का स्तर: फ़ील्ड प्रकार, फ़ील्ड की लंबाई और दर्ज किए गए डेटा का सत्यापन वास्तव में कैसे होता है।

उपयोग के मामले में क्या शामिल नहीं है, लेकिन यह हमेशा किसी न किसी तरह से जुड़ा हुआ है और इस पर विचार करना आवश्यक है: डेटा प्रारूप, इनपुट / आउटपुट प्रोटोकॉल, उपयोगकर्ता इंटरफ़ेस, उपयोगकर्ता इंटरफ़ेस डिज़ाइन, व्यावसायिक नियमों के लिए प्रदर्शन आवश्यकताओं और आवश्यकताएं।

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

जारी रखा जाए।