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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इसे एक उदाहरण से समझते हैं, यहाँ दर्शाई गई तालिका में तीन कॉलम हैं,

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

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

अब आइए इनमें से प्रत्येक आवश्यकता को विस्तार से समझते हैं: AtomI C।

Atomic

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

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

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

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

पूर्ण

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

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

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

इस आवश्यकता में समस्या यह है कि पहली आवश्यकता से ऐसा लगता है कि पाठ्यक्रमों को स्नातक पाठ्यक्रम और स्नातकोत्तर पाठ्यक्रम दो श्रेणियों में विभाजित किया गया है और छात्र दो में से किसी एक को चुन सकता है लेकिन दोनों को नहीं। लेकिन जब आप दूसरी आवश्यकता को पढ़ते हैं तो यह पहली आवश्यकता के साथ टकराव करती है और बताती है कि कुछ पाठ्यक्रम स्नातकोत्तर और स्नातक दोनों के लिए खुले होंगे।

इसलिए इस बुरी आवश्यकता को अच्छी आवश्यकता में बदलना स्वाभाविक है जो है "छात्र के पास या तो स्नातक पाठ्यक्रम या स्नातकोत्तर पाठ्यक्रम होंगे, लेकिन दोनों नहीं"। जिसका अर्थ है कि प्रत्येक पाठ्यक्रम को या तो स्नातक पाठ्यक्रम या स्नातकोत्तर पाठ्यक्रम के रूप में चिह्नित किया जाएगा।

Tracसक्षम

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

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

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

यह तो tracपूरी परियोजना में दक्षता व्याप्त है।

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

प्राथमिकता के आधार पर	पंजीकृत छात्र-प्राथमिकता 1 उपयोगकर्ता जानकारी बनाए रखें- प्राथमिकता 1 पाठ्यक्रमों में नामांकन-प्राथमिकता 1 रिपोर्ट कार्ड देखें- प्राथमिकता 1	छात्र-प्राथमिकता 1 पंजीकृत करें उपयोगकर्ता जानकारी बनाए रखें- प्राथमिकता 2 पाठ्यक्रमों में नामांकन-प्राथमिकता 1 रिपोर्ट कार्ड देखें- प्राथमिकता 3

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

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

परीक्षण योग्य	सिस्टम का प्रत्येक पृष्ठ स्वीकार्य समय-सीमा में लोड होगा	सिस्टम के छात्र पंजीकरण और पाठ्यक्रम नामांकन पृष्ठ 5 सेकंड के भीतर लोड हो जाएंगे

हर एक आवश्यकता परीक्षण योग्य होनी चाहिए, यहाँ पर खराब आवश्यकता यह है कि “सिस्टम का प्रत्येक पेज स्वीकार्य समय सीमा में लोड होगा”। अब इस आवश्यकता के साथ दो समस्याएँ हैं, पहली यह कि प्रत्येक पेज का मतलब है कि कई पेज हो सकते हैं, जो परीक्षण प्रयासों को विफल कर देंगे। दूसरी समस्या यह है कि यह कहता है कि पेज स्वीकार्य समय सीमा में लोड होने वाला है, अब स्वीकार्य समय सीमा क्या है? किसके लिए स्वीकार्य है। इसलिए हमें गैर-परीक्षण योग्य तर्क को एक परीक्षण योग्य तर्क में बदलना होगा, जो विशेष रूप से बताता है कि हम किस पेज के बारे में बात कर रहे हैं “छात्र पंजीकरण और पाठ्यक्रम नामांकन पृष्ठ” और स्वीकार्य समय सीमा भी दी गई है जो 5 सेकंड है।

निष्कर्ष

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