सॉफ्टवेयर आवश्यकताएँ: एकत्रित करने और दस्तावेजीकरण के लिए दिशानिर्देश

आज हम आपके ध्यान में इल्या कोर्निपेव की पुस्तक " सॉफ्टवेयर के लिए आवश्यकताएँ: संग्रह और प्रलेखन के लिए सिफारिशें " लाना चाहते हैं, जिसे हमारे प्रकाशन गृह में प्रकाशन के लिए तैयार किया जा रहा है।

अमूर्त

यह पुस्तक आवश्यकताओं को कैसे एकत्रित, दस्तावेज और सत्यापित करने के बारे में है। यह पाठकों की एक विस्तृत श्रृंखला के लिए डिज़ाइन किया गया है: नौसिखिया विश्लेषक, डिजाइनर, आर्किटेक्ट, डेवलपर्स, परीक्षक, परियोजना प्रबंधक, और शुरुआती सॉफ्टवेयर विकास परियोजनाओं में शामिल अन्य विशेषज्ञ।

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

अध्याय 3 से अंश।

मुख्य प्रदर्शन मानदंड

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

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

यह तुरंत समझाने योग्य है कि मैंने इस मुद्दे पर ध्यान क्यों दिया। मैंने उन स्थितियों को बार-बार देखा है जहाँ प्रदर्शन मानदंड के रूप में लिखा गया था:

21.1। सिस्टम को 2 सेकंड से अधिक किसी भी रूप में दर्ज की गई जानकारी को सहेजना होगा।
या
21.2। सिस्टम को 5 सेकंड से अधिक समय में खोज परिणाम वापस करना चाहिए।

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

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

चित्र 8 में चार प्रदर्शन मेट्रिक्स विशेषताएं हैं। अक्सर, विश्लेषक पहले फ़ंक्शन तक सीमित होते हैं, अर्थात। एक निश्चित राशि तय करें। वास्तव में, यह एक दुर्लभ मामला है।

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



चित्र 8। उत्पादकता संकेतक के एक मूल्य के कार्य।

ग्राफ c) एकमात्र अंतर होने के साथ एक समान स्थिति दिखाता है कि इस मामले में ग्राहक प्रदर्शन मानदंड के मूल्य को कम करने में रुचि रखता है। उदाहरण के लिए, खोज क्वेरी को पूरा करने में सिस्टम को लगने वाला समय 3 s से अधिक नहीं होना चाहिए। हालांकि यह ग्राफ से चलता है कि सिस्टम 5 एस के मूल्य तक पहुंचता है, लगभग 90% ग्राहक संतुष्टि देता है, और यहां तक ​​कि 7 एस लगभग 70% देता है, इसलिए, जैसा कि ग्राफ दिखाता है, सब कुछ 7 एस से बेहतर है, लेकिन 3 एस से कम हो सकता है, ग्राहक द्वारा स्वीकार किए जाते हैं, अतिरिक्त बातचीत के बाद और सबसे अधिक संभावना है, भविष्य में मुक्त प्रणाली के विकास के अधीन। टीम परियोजना को समय पर वितरित कर सकती है, और फिर अगली डिलीवरी में प्रारंभिक आवश्यकताओं के अनुसार प्रणाली में सुधार कर सकती है।

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

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

विषय-सूची

प्रस्तावना
प्रमुख प्रश्न: क्यों? किसके लिए? क्या?
इस किताब को कैसे पढ़ें। पुस्तक की संरचना। दायित्व की सीमा

परिचय
आवश्यकताएं क्या हैं?
सिस्टम डेवलपमेंट कम्युनिकेशन
समस्या क्षेत्र और समाधान क्षेत्र
आवश्यकताओं और समाधान की पसंद की संख्या
समाधान के क्षेत्र में समय से पहले संक्रमण से जुड़ी समस्याएं
ग्राहकों की अपेक्षाओं का प्रबंधन करना
आवश्यकताओं के प्रकार
आवश्यकताओं और गुणवत्ता
आवश्यकताएँ और मॉडलिंग
आवश्यकताएँ और परिवर्तन
परिवर्तन का स्रोत - ग्राहक
परिवर्तन के स्रोत के रूप में बाजार
परिवर्तन के स्रोत के रूप में डेवलपर्स
अन्य विशेषता कठिनाइयों
उच्च अनिश्चितता
परियोजना के प्रतिभागियों के विभिन्न सांस्कृतिक और शैक्षिक स्तर
विरोधाभासों
प्राकृतिक भाषा का उपयोग करना
स्कोप और आवश्यकताओं की गहराई
आवश्यकताएँ विकास प्रक्रिया अवलोकन
अध्याय 1. हितधारकों और उनके प्रतिनिधियों की पहचान
परियोजना में हितधारकों
आवश्यकताओं को एकत्र करने के लिए हितधारक प्रतिनिधियों की पहचान
बातचीत का आरेख
हितधारक प्रतिनिधि चयन
हितधारकों और उनके लक्ष्यों
हितधारकों और उनकी चिंताओं
निष्कर्ष
अध्याय 2. आवश्यकताओं का संग्रह
आवश्यकताओं के स्रोतों का अवलोकन
आवश्यकताएँ संग्रह योजना
आवश्यकताओं को एकत्रित करने के स्रोत के रूप में लोग
बैठक की तैयारी
साक्षात्कार
बैठक कैसे शुरू होती है?
कैसे बैठेंगे?
संपर्क करें
परिचय
क्यू एंड ए
बैठक का अंत
बैठक के बाद
टेलीफोन कॉल
पत्र-व्यवहार
समूह की बैठकें
कार्यशाला कार्यशाला
पोल
आवश्यकताओं को प्राप्त करने के अन्य तरीके
लोगों के काम का पर्यवेक्षण
सिस्टम के भविष्य के उपयोगकर्ताओं के वर्तमान काम के विश्लेषक द्वारा अस्थायी निष्पादन
विशेषज्ञ और सलाहकार
प्रणाली
दस्तावेजों
समर्थन कॉल
प्रोटोटाइप
खतरनाक प्रोटोटाइप
निष्कर्ष
अध्याय 3. एकत्रित आवश्यकताओं के साथ काम करना
क्या एक अच्छा दस्तावेज़ के साथ शुरू होता है
आवश्यकताएँ संरचना
आवश्यकताएँ पाठ
आवश्यकता गुण
प्रमुख आवश्यकताएं
मुख्य प्रदर्शन मानदंड
निष्कर्ष
अध्याय 4. आवश्यकताओं की जाँच
चेकों का महत्व
चेकों के प्रकार
सहकर्मी की समीक्षा (सहकर्मी की समीक्षा)
आवश्यकता पाठ मान्यता मानदंड
आवश्यकताओं का एक पूरा सेट के लिए मानदंड
चेकों के बारे में थोड़ा और
निष्कर्ष
साहित्य