उदाहरण के साथ सॉफ्टवेयर आवश्यकता विश्लेषण

सॉफ्टवेयर आवश्यकता एक कार्यात्मक या गैर-कार्यात्मक ज़रूरत है जिसे सिस्टम में लागू किया जाना चाहिए। कार्यात्मक का अर्थ है उपयोगकर्ता को विशिष्ट सेवा प्रदान करना।

उदाहरण के लिए, बैंकिंग एप्लिकेशन के संदर्भ में, कार्यात्मक आवश्यकता यह है कि जब कोई ग्राहक "बैलेंस देखें" का चयन करता है, तो उसे अपना नवीनतम खाता बैलेंस देखने में सक्षम होना चाहिए।

सॉफ्टवेयर संबंधी आवश्यकता गैर-कार्यात्मक भी हो सकती है, जैसे कि प्रदर्शन संबंधी आवश्यकता। उदाहरण के लिए, एक गैर-कार्यात्मक आवश्यकता यह हो सकती है कि सिस्टम का प्रत्येक पृष्ठ उपयोगकर्ताओं के लिए 5 सेकंड के भीतर लोड हो जाना चाहिए।

तो, मूलतः सॉफ्टवेयर की आवश्यकता है

• कार्यात्मक या
• नॉन-फंक्शनल

आवश्यकता जिसे प्रणाली में लागू किया जाना है। सॉफ्टवेयर संबंधी आवश्यकताओं को आमतौर पर कथनों के रूप में व्यक्त किया जाता है।

आवश्यकताओं के प्रकार

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

देश	बैंकिंग कार्यक्षमता या सेवाएं प्रदान करने वाली कंपनी
इंडिया	खाता सारांश और निधि स्थानांतरण
चीन	खाता सारांश और Bill भुगतान

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

बैंकिंग उपयोग मामला

आवश्यकता

Bill भुगतान

यह उपयोग मामला बताता है कि ग्राहक नेट बैंकिंग में कैसे लॉगिन कर सकता है और इसका उपयोग कैसे कर सकता है Bill भुगतान सुविधा। ग्राहक पंजीकृत बिलदाताओं के बकाया बिलों का डैशबोर्ड देख सकते हैं। ग्राहक बिलदाता का विवरण जोड़, संशोधित और हटा सकते हैं। ग्राहक विभिन्न बिलिंग कार्यों के लिए एसएमएस और ईमेल अलर्ट कॉन्फ़िगर कर सकते हैं। ग्राहक पिछले भुगतान किए गए बिलों का इतिहास देख सकते हैं। इस उपयोग के लिए बैंक ग्राहक या सहायता कर्मी जिम्मेदार हैं।

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

Bill भुगतान	आवश्यकताएँ
जोड़ना Billनेताओं	यूटिलिटी प्रदाता का नाम, ग्राहक संख्या, स्वचालित भुगतान – हाँ/नहीं, पूरी राशि का भुगतान करें Bill – हां/नहीं, स्वचालित भुगतान सीमा – यदि भुगतान न करें Bill निर्दिष्ट राशि से अधिक है

कभी-कभी किसी प्रोजेक्ट के लिए आपको कोई आवश्यकताएँ या दस्तावेज़ प्राप्त नहीं होते हैं। फिर भी, आवश्यकता संबंधी जानकारी के अन्य स्रोत मौजूद हैं जिन पर आप अपने सॉफ़्टवेयर या परीक्षण डिज़ाइन के लिए भरोसा कर सकते हैं। जिन अन्य स्रोतों पर आप भरोसा कर सकते हैं, वे नीचे सूचीबद्ध हैं।

आवश्यकताओं के अन्य स्रोत

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

आप आवश्यकताओं के जिस भी स्रोत का उपयोग करें, उन्हें एक साझा प्रारूप में दस्तावेज़ित करें और अनुभवी टीम सदस्यों द्वारा उनकी समीक्षा करवाएं।

आवश्यकताओं का विश्लेषण कैसे करें

एक ऐसे शैक्षिक सॉफ्टवेयर सिस्टम का उदाहरण लें जहां एक छात्र विभिन्न पाठ्यक्रमों के लिए पंजीकरण कर सकता है।

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

• Atomic
• विशिष्ट रूप से पहचाना गया
• पूर्ण
• सुसंगत एवं स्पष्ट
• Tracसक्षम
• प्राथमिकता के आधार पर
• परीक्षण योग्य

निम्नलिखित तालिका प्रत्येक विशेषता को तीन स्तंभों के साथ दर्शाती है:

1. पहला कॉलम इंगित करता है- “आवश्यकता गुणवत्ता”
2. दूसरा कॉलम इंगित करता है- “कुछ समस्या के साथ खराब आवश्यकता”
3. तीसरे कॉलम में वही आवश्यकता "एक अच्छी आवश्यकता में परिवर्तित" दिखाई गई है।

आवश्यकता गुणवत्ता	ख़राब आवश्यकता का उदाहरण	अच्छी आवश्यकता का उदाहरण
Atomic	छात्र स्नातक और स्नातकोत्तर पाठ्यक्रमों में नामांकन ले सकेंगे	छात्र स्नातक पाठ्यक्रमों में दाखिला ले सकेंगे। छात्र स्नातकोत्तर पाठ्यक्रमों में दाखिला ले सकेंगे।
विशिष्ट रूप से पहचाना गया	1- छात्र स्नातक पाठ्यक्रमों में दाखिला ले सकेंगे। 1- छात्र स्नातकोत्तर पाठ्यक्रमों में दाखिला ले सकेंगे।	कोर्स में नामांकन। छात्र स्नातक पाठ्यक्रमों में नामांकन कर सकेंगे। छात्र स्नातकोत्तर पाठ्यक्रमों में नामांकन कर सकेंगे।
पूर्ण	एक प्रोफेसर उपयोगकर्ता अपना उपयोगकर्ता नाम, पासवर्ड और अन्य प्रासंगिक जानकारी प्रदान करके सिस्टम में लॉग इन करेगा	एक प्रोफेसर उपयोगकर्ता अपना उपयोगकर्ता नाम, पासवर्ड और विभाग कोड प्रदान करके सिस्टम में लॉग इन करेगा
सुसंगत एवं स्पष्ट	एक छात्र के पास या तो स्नातक पाठ्यक्रम या स्नातकोत्तर पाठ्यक्रम होंगे, लेकिन दोनों नहीं। कुछ पाठ्यक्रम स्नातक और स्नातकोत्तर दोनों के लिए खुले होंगे	एक छात्र के पास या तो स्नातक या स्नातकोत्तर की डिग्री होगी, लेकिन दोनों नहीं
Tracसक्षम	क्या छात्र सूचना को BRD req.ID से मैप करके रखना संभव है?	छात्र जानकारी बनाए रखें-बीआरडी आवश्यकता आईडी 4.1 से मैप करें
प्राथमिकता के आधार पर	पंजीकृत छात्र-प्राथमिकता 1. उपयोगकर्ता जानकारी बनाए रखना-प्राथमिकता 1. पाठ्यक्रमों में नामांकन करना-प्राथमिकता 1. रिपोर्ट कार्ड देखना-प्राथमिकता 1	छात्र पंजीकरण - प्राथमिकता 1. उपयोगकर्ता जानकारी बनाए रखना - प्राथमिकता 2. पाठ्यक्रमों में नामांकन - प्राथमिकता 1. रिपोर्ट कार्ड देखना - प्राथमिकता 3
परीक्षण योग्य	सिस्टम का प्रत्येक पृष्ठ स्वीकार्य समय-सीमा में लोड होगा	सिस्टम के छात्र पंजीकरण और पाठ्यक्रम नामांकन पृष्ठ 5 सेकंड के भीतर लोड हो जाएंगे

आइए इनमें से प्रत्येक विशेषता को और अधिक विस्तार से समझते हैं, शुरुआत करते हुए। AtomI C।

Atomic

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

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

विशिष्ट रूप से पहचाना गया

अगली गुणवत्ता विशेषता विशिष्ट पहचान है। खराब उदाहरण में, दो अलग-अलग आवश्यकताओं का एक ही ID#1 है। यदि कोई टीम किसी आवश्यकता को उसके ID से संदर्भित करती है, तो यह स्पष्ट नहीं हो पाता कि दोनों में से किसका उल्लेख किया जाना है। अच्छी आवश्यकता उन्हें अनुभाग 1 - पाठ्यक्रम नामांकन के अंतर्गत पुनर्समूहित करती है, जिसमें उप-आवश्यकताएँ 1.1 (स्नातकोत्तर पाठ्यक्रमों में नामांकन) और 1.2 (स्नातकोत्तर पाठ्यक्रमों में नामांकन) शामिल हैं।

पूर्ण

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

सुसंगत एवं स्पष्ट

प्रत्येक आवश्यकता सुसंगत और स्पष्ट होनी चाहिए। गलत उदाहरण में, एक आवश्यकता कहती है कि "एक छात्र के पास या तो स्नातक पाठ्यक्रम होंगे या स्नातकोत्तर पाठ्यक्रम, लेकिन दोनों नहीं", जबकि दूसरी कहती है कि "कुछ पाठ्यक्रम स्नातक और स्नातकोत्तर दोनों छात्रों के लिए खुले होंगे"।

पहली शर्त के अनुसार पाठ्यक्रमों को दो विशिष्ट श्रेणियों में विभाजित किया जाना चाहिए, लेकिन दूसरी शर्त इसका खंडन करती है क्योंकि इसमें कुछ पाठ्यक्रम दोनों समूहों के लिए खुले होते हैं।

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

Tracसक्षम

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

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

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

Tracइसलिए, यह क्षमता परियोजना के शुरू से अंत तक लागू होती है।

प्राथमिकता के आधार पर

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

परीक्षण योग्य

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

अक्सर पूछे जाने वाले प्रश्न