2.8 सॉफ़्टवेयर आवश्यकताएँ

अवलोकन और प्रेरणा

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

बड़ी टीमों के लिए, आवश्यकताएँ वह साझा समझ हैं जो कई लोगों को एक सुसंगत सिस्टम बनाने देती हैं। एक अकेला डेवलपर इरादे को अपने दिमाग में रख सकता है; कई टीमों में सैकड़ों लोग नहीं रख सकते। आवश्यकताएँ उन लोगों के बीच अनुबंध बन जाती हैं जिन्हें एक क्षमता की आवश्यकता है और जो इसे बनाते हैं, टीमों में काम विभाजित करने का आधार, और यह आँकने का पैमाना कि कोई चीज़ कब “पूर्ण” है। ये सीधे डिस्कवरी (अध्याय 11.1) से जुड़ती हैं, जहाँ समस्याएँ और अवसर सामने आते हैं; UX फ़ाउंडेशन (अध्याय 5.1) से, जहाँ आप उपयोगकर्ता आवश्यकताओं को समझते हैं; API और इंटरफ़ेस डिज़ाइन (अध्याय 2.3) से, जहाँ इंटरफ़ेस बाध्यताएँ तय होती हैं; आर्किटेक्चर और गुणवत्ता विशेषताएँ (अध्याय 3.1) से, जहाँ गैर-कार्यात्मक आवश्यकताएँ संरचना चलाती हैं; और परियोजना प्रबंधन (अध्याय 10.6) से, जहाँ दायरा, लागत, और शेड्यूल उनके इर्द-गिर्द योजना बनाया जाता है।

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

मुख्य सिद्धांत

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

सिफारिशें

आवश्यकताओं को स्पष्ट रूप से परिभाषित करें और उन्हें वर्गीकृत करें

श्रेणियों को जानबूझकर नाम दें। कार्यात्मक आवश्यकताएँ बताती हैं कि सिस्टम को क्या करना चाहिए: व्यवहार, परिवर्तन, और सेवाएँ जो यह प्रदान करता है। गैर-कार्यात्मक आवश्यकताएँ (गुणवत्ता विशेषताएँ) बताती हैं कि उसे कितनी अच्छी तरह करना चाहिए: प्रदर्शन, उपलब्धता, सुरक्षा, प्रयोज्यता, एक्सेसिबिलिटी, अनुरक्षणीयता, और अधिक; ये आर्किटेक्चर (अध्याय 3.1) से कसकर बँधी हैं। बाधाएँ (constraints) समाधान पर गैर-परक्राम्य सीमाएँ हैं: अनिवार्य तकनीकें, मानक, बजट, कानूनी नियम, या मौजूदा सिस्टमों के इंटरफ़ेस। और व्यावसायिक आवश्यकताओं (संगठन सिस्टम क्यों चाहता है) को उपयोगकर्ता आवश्यकताओं (उपयोगकर्ताओं को क्या पूरा करना चाहिए) से और सिस्टम आवश्यकताओं (सॉफ़्टवेयर को इसलिए क्या करना चाहिए) से अलग करें। इन स्तरों को एक साथ धुंधला करें और दायरा भ्रम जल्द ही उसके पीछे आता है।

वास्तविक स्रोतों से प्राप्त करें, मान्यताओं से नहीं

प्राप्ति (elicitation) सक्रिय खोज है। साक्षात्कार, कार्यशालाओं, अवलोकन, प्रोटोटाइप, और मौजूदा सिस्टम और दस्तावेज़ों के विश्लेषण के माध्यम से हितधारकों से आवश्यकताएँ निकालें। हर प्रासंगिक हितधारक का पता लगाएँ, जिनमें अनदेखी करने में आसान लोग शामिल हैं: ऑपरेटर, ऑडिटर, सहायता स्टाफ, और सिस्टम से प्रभावित लोग जो इसे कभी सीधे उपयोग नहीं करते। प्राप्ति को डिस्कवरी पाइपलाइन (अध्याय 11.1) और UX अनुसंधान (अध्याय 5.1) से जोड़ें, ताकि बताई गई इच्छाएँ अंतर्निहित आवश्यकताओं तक वापस ट्रेस हों। हर आवश्यकता का स्रोत और तर्क रिकॉर्ड करें, क्योंकि यह जानना कि एक आवश्यकता क्यों मौजूद है वही है जो आपको इसे बाद में सुरक्षित रूप से बदलने देता है।

विश्लेषण करें, बातचीत करें, और प्राथमिकता दें

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

सही औपचारिकता स्तर पर निर्दिष्ट करें

आवश्यकताओं को एक ऐसे रूप में लिखें जो जोखिम और दर्शकों में फिट बैठे। एक उच्च-आश्वासन वाला सरकारी सिस्टम IEEE 29148 जैसे मानक के अनुरूप संरचित एक औपचारिक विनिर्देश की वारंट कर सकता है; एक तेज़ी से आगे बढ़ने वाली उत्पाद टीम बैकलॉग में स्वीकृति मानदंड के साथ उपयोगकर्ता कहानियों के रूप में आवश्यकताओं को कैप्चर कर सकती है। किसी भी तरह, हर आवश्यकता परमाणु, सत्यापन योग्य, और “fast,” “user-friendly,” या “etc.” जैसे फिसलन भरे शब्दों से मुक्त होनी चाहिए। स्वीकृति मानदंड संलग्न करें, ताकि आप उसी क्षण परिभाषित करें कि आवश्यकता को कैसे सत्यापित करना है जब आप इसे लिखते हैं। और एक आधिकारिक स्रोत रखें, बजाय इसके कि आवश्यकताओं को ईमेल, टिकट, और स्लाइड में बिखरने दें।

बनाने से पहले मान्य करें

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

आवश्यकताओं का प्रबंधन करें और ट्रेसेबिलिटी बनाए रखें

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

एजाइल और योजना-संचालित संदर्भों के अनुकूल बनें

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

ट्रेड-ऑफ़: पक्ष और विपक्ष

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

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

हमारे सबसे उच्च-जोखिम वाले सिस्टम के लिए हितधारक कौन गिना जाता है, और हम स्वीकृति तक किन्हें छोड़ते रहते हैं? एक बड़े कार्यक्रम में जो लोग छूट जाते हैं वे शायद ही कभी स्पष्ट उपयोगकर्ता होते हैं: वे ऑपरेटर हैं जो इसे रात 3 बजे चलाते हैं, ऑडिटर जिन्हें इसे प्रमाणित करना है, सहायता स्टाफ जो विफलताओं को संभालते हैं, और प्रभावित गैर-उपयोगकर्ता जो कभी लॉग इन नहीं करते लेकिन जिनका डेटा आप रखते हैं। उन्हें चूकें और आप उनकी आवश्यकताओं को सबसे महँगे क्षण पर खोजते हैं, स्वीकृति के दौरान या एक नियामक के पूछने के बाद। बैठक में एक ठोस हितधारक मानचित्र लाएँ और इसे तनाव-परीक्षण करें: हर अनिवार्य बाध्यता (एक्सेसिबिलिटी, गोपनीयता, रिकॉर्ड प्रतिधारण, सुरक्षा) के लिए उस व्यक्ति का नाम बताएँ जो इसका मालिक है और वह आवश्यकता जो इसे कैप्चर करती है। यदि आप एक मालिक का नाम नहीं बता सकते, तो आपको एक अंतराल मिल गया है, और समाधान उस हितधारक को अभी प्राप्ति में जोड़ना है बजाय इसके कि बाद में एक निश्चित आर्किटेक्चर में उनकी ज़रूरतों को रेट्रोफ़िट करें।
जब कोई आवश्यकता बदलती है, तो क्या हम परिवर्तन को स्वीकृत करने से पहले बता सकते हैं कि यह क्या प्रभावित करती है? यह इस बात का व्यावहारिक परीक्षण है कि क्या आपकी द्विदिश ट्रेसेबिलिटी वास्तविक है या सजावटी। एक बड़े या विनियमित सिस्टम में एक ही नियम परिवर्तन डिज़ाइन, कोड, परीक्षण, और स्वीकृति साक्ष्य में फैल सकता है, और इसे अंधाधुंध स्वीकृत करना ही है कि कैसे आप एक अनुपालक-दिखने वाला सिस्टम शिप करते हैं जो चुपचाप एक ऐसे नियम का उल्लंघन करता है जिसे वह पहले संतुष्ट करता था। एक हालिया परिवर्तन अनुरोध लाएँ और बैठक में इसे आगे ट्रेस करने की कोशिश करें: यदि इसमें एक दोपहर की पुरातत्व लगती है, तो आपकी ट्रेसेबिलिटी अपना काम नहीं कर रही है। उत्तर को आपकी परिवर्तन प्रक्रिया को फिर से आकार देना चाहिए, ताकि प्रभाव आकलन एक मैनुअल खोज के बजाय एक जीवित ट्रेस के खिलाफ़ एक तेज़ क्वेरी हो, और ताकि बेसलाइन और वर्जनिंग आपको बदलाव के खिलाफ़ एक स्थिर बिंदु दें।
हमारी आवश्यकताओं का एकल आधिकारिक स्रोत कहाँ रहता है, और इसके बाहर कितना सत्य बिखरा हुआ है? आवश्यकता फैलाव (वास्तविक स्पेक ईमेल, टिकट, स्लाइड, और किसी की याददाश्त में रहना) बड़ी टीमों पर सबसे आम विफलताओं में से एक है, और यह ऑडिटेड सिस्टम में घातक है जहाँ आपको दिखाना होता है कि क्या सहमत हुआ था। ज़ोर से तय करें कि कौन सा सिस्टम-ऑफ़-रिकॉर्ड कैनोनिकल है, और अन्यत्र बताई गई किसी भी चीज़ को एक ड्राफ्ट मानें जब तक कि यह अपने स्रोत और तर्क के साथ वहाँ न पहुँच जाए। साक्ष्य लाएँ: गिनें कि हाल के कितने दायरा विवाद दो लोगों के अलग-अलग “अंतिम” संस्करणों का हवाला देने पर उतरे। यदि गिनती शून्य से अधिक है, तो कार्रवाई एक स्रोत में समेकित करना और हर आवश्यकता के लिए तर्क लिखना है, क्योंकि यह जानना कि एक आवश्यकता क्यों मौजूद है वही है जो आपको इसे बाद में सुरक्षित रूप से बदलने या छोड़ने देता है।
क्या हमारी गैर-कार्यात्मक आवश्यकताएँ आर्किटेक्चर चलाने के लिए काफ़ी जल्दी कैप्चर की गई हैं, या हम उन्हें संरचना तय होने के बाद खोजते रहते हैं? प्रदर्शन, उपलब्धता, सुरक्षा, और एक्सेसिबिलिटी बाध्यताएँ अधिकांश सुविधाओं से अधिक आर्किटेक्चर को आकार देती हैं, और एक बड़े कार्यक्रम में ये वे आवश्यकताएँ हैं जो अक्सर बहुत देर से सामने आती हैं, एक बार जब वह संरचना जिसे उन्हें संतुष्ट करना होगा पहले से कंक्रीट में डाली जा चुकी होती है। प्रतिस्पर्धी खिंचाव वास्तविक है: कार्यात्मक व्यवहार वह है जिसे हितधारक ज़ोर से माँगते हैं और अच्छी तरह डेमो करते हैं, जबकि एक “पीक लोड के तहत सब-सेकंड प्रतिक्रिया” या “WCAG एक्सेसिबिलिटी अनुरूपता” आवश्यकता तब तक अदृश्य है जब तक इसका उल्लंघन नहीं होता। अपने सबसे उच्च-जोखिम वाले सिस्टम के लिए गैर-कार्यात्मक आवश्यकताओं की वर्तमान सूची लाएँ, टाइमलाइन में वह बिंदु जब प्रत्येक लिखी गई थी, और क्या आर्किटेक्चर (अध्याय 3.1) ने उन्हें स्पष्ट चालकों के रूप में प्राप्त किया या उनका अनुमान लगाया। उद्यम और सरकारी सेटिंग में, अनिवार्य गुणवत्ता बाध्यताएँ (एन्क्रिप्शन, रिकॉर्ड प्रतिधारण, एक्सेसिबिलिटी कानून) जोड़ें और जाँचें कि प्रत्येक एक लिखित, मापने योग्य आवश्यकता है जो डिज़ाइन को सौंपी गई है बजाय एक धारणा के, क्योंकि स्वीकृति के बाद एक गुणवत्ता विशेषता को रेट्रोफ़िट करना वह जगह है जहाँ बजट और शेड्यूल चुपचाप मर जाते हैं।
हमारे स्वामित्व वाले हर सिस्टम के लिए कौन सा औपचारिकता स्तर सही है, और क्या हम इसे जोखिम से चुनते हैं या आदत से? एक अकेला बड़ा संगठन आम तौर पर सिस्टमों की एक श्रृंखला चलाता है, एक फेंकने-योग्य आंतरिक टूल से लेकर एक जीवन-या-सुरक्षा विनियमित प्लेटफ़ॉर्म तक, और उन सभी पर एक ही समारोह लागू करना या तो कम-जोखिम वाले काम को कागज़ी कार्रवाई में दफ़न कर देता है या उच्च-जोखिम वाले काम को कम-निर्दिष्ट छोड़ देता है। तनाव औपचारिक अग्रिम विनिर्देश की ऑडिटेबिलिटी और ठोस स्वीकृति आधार, और एक विकसित होते बैकलॉग के तेज़ फ़ीडबैक और कम बर्बादी के बीच है, और अधिकांश उद्यमों के लिए ईमानदार उत्तर एक जानबूझकर मिश्रण है: स्थिर, उच्च-आश्वासन बाध्यताओं को औपचारिक बनाएँ और ट्रेस करें जबकि उत्पाद व्यवहार को पुनरावृत्तीय रूप से विस्तृत करें। विफलता के परिणाम, नियामक जोखिम, और परिवर्तन की दर से रैंक की गई अपने सिस्टमों की एक छोटी सूची लाएँ, और हर एक के लिए वह औपचारिकता बताएँ जिसका आप वास्तव में उपयोग करते हैं बनाम वह औपचारिकता जो जोखिम वारंट करता है। एक सरकारी कार्यक्रम के लिए जो एक याचना और IEEE 29148 जैसे मानक पर आधारित है, औपचारिकता आंशिक रूप से अनुबंध द्वारा निर्धारित होती है, इसलिए चर्चा यह है कि आप उस ट्रेसेबिलिटी को तोड़े बिना, जिस पर ऑडिट निर्भर करता है, इसके ऊपर एजाइल विस्तार की परत कहाँ लगा सकते हैं।
क्या हमारे सबसे उच्च-जोखिम वाले सिस्टम में हर आवश्यकता को सत्यापित किया जा सकता है, और क्या हर एक स्वीकृति मानदंड रखता है जो आवश्यकता के समय ही लिखा गया था? एक ऐसी आवश्यकता जिसे आप सत्यापित नहीं कर सकते वह एक आवश्यकता नहीं है, यह एक इच्छा है, और “fast,” “secure,” या “user-friendly” जैसे फिसलन भरे शब्द ठीक इसलिए समीक्षा पास कर जाते हैं क्योंकि कोई उन्हें विफल नहीं कर सकता। एक बड़ी टीम के लिए यह दोगुना मायने रखता है: असत्यापन योग्य आवश्यकताएँ स्वीकृति पर दायरा विवाद पैदा करती हैं, और वे यह कहना असंभव बना देती हैं कि एक सुविधा वास्तव में कब पूर्ण होती है। प्रतिस्पर्धी विचार गति है, क्योंकि हर आवश्यकता से एक मापने योग्य मानदंड और सत्यापन विधि जोड़ना गद्य लिखने की तुलना में अग्रिम रूप से धीमा है, लेकिन यह सबसे महँगे देर से होने वाले पुनर्कार्य के खिलाफ़ सबसे सस्ता बचाव है। हाल की आवश्यकताओं का एक नमूना लाएँ और हर एक को एक सरल बार के खिलाफ़ परखें: क्या यह परमाणु है, क्या यह मापने योग्य है, और क्या यह बताती है कि इसे कैसे जाँचा जाएगा। विनियमित और सरकारी संदर्भों में, परीक्षण को साक्ष्य तक विस्तारित करें: बिना ट्रेस किए, पास होते स्वीकृति साक्ष्य वाली एक आवश्यकता को डिलीवर किया हुआ नहीं माना जाता, चाहे सॉफ़्टवेयर जो भी दिखता हो, इसलिए स्वीकृति मानदंड उस अनुपालन रिकॉर्ड का बीज हैं जिसे आपको अंततः निर्मित करना होगा।

क्षेत्र लेंस

स्टार्टअप। एक छोटी टीम और थोड़े रनवे के साथ, आवश्यकताओं को उतना हल्का रखें जितना आप बच सकें: एक साझा बैकलॉग में स्वीकृति मानदंड वाली उपयोगकर्ता कहानियाँ, एक विनिर्देश दस्तावेज़ नहीं। वह अनुशासन जो यहाँ भी लाभदायक है वह है बनाने से पहले वास्तविक उपयोगकर्ताओं से बात करना और हर कहानी का स्रोत और तर्क रिकॉर्ड करना, ताकि जो सप्ताह आप गलत सुविधा बनाने में बर्बाद कर देते वह वह सप्ताह हो जो आप बचाते हैं। औपचारिक ट्रेसेबिलिटी छोड़ें, लेकिन उस बातचीत को कभी न छोड़ें जो आपको बताती है कि वास्तविक आवश्यकता क्या है।

लघु व्यवसाय। आपके पास संभवतः कोई बिज़नेस एनालिस्ट या आवश्यकता विशेषज्ञ नहीं है, इसलिए काम उसके पास आता है जो ग्राहक के सबसे नज़दीक है, और खरीद-बनाम-निर्माण प्रश्न हावी रहता है। आवश्यकताओं को उन परिणामों की एक छोटी, प्राथमिकता वाली सूची के रूप में तैयार करें जिनकी आपको आवश्यकता है, फिर इसका उपयोग एक बेस्पोक निर्माण को निर्दिष्ट करने के बजाय ऑफ़-द-शेल्फ़ टूल का मूल्यांकन करने के लिए करें। अंतर्निहित आवश्यकता को एक विक्रेता की सुविधा सूची से अलग करने के बारे में सख्त रहें, क्योंकि “we need product X” के रूप में लिखी गई एक आवश्यकता चुपचाप सस्ते विकल्पों को बंद कर देती है जो वास्तविक आवश्यकता को पूरा कर सकते थे।

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

सरकार। खरीद नियम अक्सर पूरे अनुबंध को एक आवश्यकता विनिर्देश के इर्द-गिर्द बनाते हैं, जो अक्सर IEEE 29148 जैसे मानक के अनुरूप संरचित होता है, इसलिए सटीकता और पूर्णता संविदात्मक हैं, वैकल्पिक नहीं। एक आवश्यकता ट्रेसेबिलिटी मैट्रिक्स बनाए रखें जो हर आवश्यकता को डिज़ाइन, परीक्षण मामलों, और स्वीकृति साक्ष्य से जोड़ता है, क्योंकि विक्रेता भुगतान, ऑडिट, और संचालन का अधिकार सब प्रदर्शित कवरेज पर निर्भर करते हैं। पारदर्शिता और सार्वजनिक जवाबदेही बार को और ऊँचा करते हैं: एक्सेसिबिलिटी, गोपनीयता, और रिकॉर्ड प्रतिधारण के लिए अनिवार्य बाध्यताओं को प्रत्येक एक स्पष्ट, सत्यापन योग्य आवश्यकता के रूप में दिखना चाहिए, और बिना ट्रेस किए, पास होते साक्ष्य वाली एक आवश्यकता को बस डिलीवर नहीं किया गया माना जाता।

उदाहरण

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

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

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

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

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

एंटी-पैटर्न और नुकसान

आवश्यकताओं के रूप में छद्म वेश धारण किए समाधान: अंतर्निहित आवश्यकता के बजाय एक चुनी गई तकनीक या स्क्रीन लेआउट को निर्दिष्ट करना, बेहतर विकल्पों को बंद करना।
अस्पष्ट भाषा: बिना किसी मापने योग्य मानदंड के “fast,” “secure,” “intuitive,” आवश्यकता को असत्यापन योग्य बनाना।
गोल्ड-प्लेटिंग: ऐसी आवश्यकताएँ कैप्चर करना जिनकी किसी हितधारक को वास्तव में आवश्यकता नहीं है, दायरे और लागत को फुलाना।
गुम गैर-कार्यात्मक आवश्यकताएँ: आर्किटेक्चर तय होने के बाद ही प्रदर्शन, सुरक्षा, या एक्सेसिबिलिटी बाध्यताओं को खोजना।
आवश्यकता फैलाव: बिना किसी आधिकारिक स्रोत के ईमेल, टिकट, और स्लाइड में बिखरा हुआ सत्य।
फ्रोज़न या अनियंत्रित परिवर्तन: या तो सभी परिवर्तन को अस्वीकार करना या प्रभाव आकलन के बिना हर परिवर्तन को स्वीकार करना।
कोई ट्रेसेबिलिटी नहीं: यह उत्तर देने में असमर्थता कि एक परिवर्तन क्या प्रभावित करता है या एक सुविधा क्यों मौजूद है, ऑडिटेड सिस्टम में घातक।
विश्लेषण पक्षाघात (analysis paralysis): अंतहीन विनिर्देश जो काम करने वाले सॉफ़्टवेयर से सीखने में देरी करता है।
अनदेखे हितधारक: ऑपरेटर, ऑडिटर, और प्रभावित गैर-उपयोगकर्ता स्वीकृति तक छोड़े गए।

परिपक्वता मॉडल

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

चर्चा के लिए विचार

जब एक वरिष्ठ हितधारक इसे एक समाधान के रूप में बताता है तो आप एक वास्तविक आवश्यकता को एक समयपूर्व समाधान से कैसे अलग करते हैं?
आपके सबसे उच्च-जोखिम वाले सिस्टम बनाम आपके सबसे कम-जोखिम वाले सिस्टम के लिए कौन सा आवश्यकता औपचारिकता स्तर सही है, और कौन तय करता है?
आप एक तेज़ी से आगे बढ़ने वाले एजाइल बैकलॉग में द्विदिश ट्रेसेबिलिटी को इसे नौकरशाही बोझ बने बिना कैसे वर्तमान रखते हैं?
आपके संगठन में कौन सी गैर-कार्यात्मक आवश्यकताएँ अक्सर बहुत देर से खोजी जाती हैं, और क्यों?
एक विनियमित कार्यक्रम में, पर्याप्त स्वीकृति साक्ष्य क्या माना जाता है कि एक आवश्यकता पूरी हुई थी?
AI-सहायता प्राप्त प्राप्ति और विनिर्देश टूल को आपके आवश्यकता अभ्यास को कैसे बदलना चाहिए, और वे कौन से नए जोखिम पेश करते हैं?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

IEEE and ISO/IEC, Guide to the Software Engineering Body of Knowledge (SWEBOK), Software Requirements knowledge area
Karl Wiegers and Joy Beatty, Software Requirements
ISO/IEC/IEEE 29148, Systems and software engineering: Life cycle processes: Requirements engineering
Suzanne Robertson and James Robertson, Mastering the Requirements Process
Dean Leffingwell, Agile Software Requirements
Mike Cohn, User Stories Applied
Ian Sommerville, Software Engineering (requirements engineering chapters)