सॉफ्टवेयर डिजाइन: स्वीकृति मानदंड क्या है और आपको इसकी आवश्यकता क्यों है?

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

यहाँ आप के साथ आ रहे हैं; आप की जरूरत है:-

  • उपयोगकर्ता नाम और पासवर्ड के लिए इनपुट बॉक्स
  • एक सबमिट बटन
  • किसी उपयोगकर्ता को यह बताने का कोई तरीका है कि क्या उन्होंने गलत तरीके से अपना विवरण दर्ज किया है
  • भूल गए ब्योरे को पुनर्प्राप्त करने का कोई तरीका
  • किसी खाते के लिए साइन अप करने का कुछ तरीका अगर उनके पास पहले से कोई नहीं है

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

तो, क्या यह पर्याप्त है?

वैसे, अगर आप किसी प्रकार का व्यवहार परीक्षण लिखना चाहते हैं, तो क्या होगा? आप उपयोगकर्ता चरणों में ऊपर क्या अनुवाद करते हैं? और क्या इस तरह का 'शॉर्ट टैगलाइन' दृष्टिकोण आपको इस बारे में पर्याप्त बताता है कि कोई उपयोगकर्ता वास्तव में इन चीजों को कैसे करता है? क्या आपने माना है कि उपयोगकर्ता द्वारा सफलतापूर्वक लॉग इन करने के बाद क्या होता है? क्या यह दृष्टिकोण उस तरह के विचार को प्रोत्साहित करता है?

हमें पता है कि हमें क्या चाहिए, लेकिन यह एक अच्छी तरह से डिज़ाइन की गई सुविधा में कैसे अनुवाद करता है?

आपने शायद जवाब का अनुमान लगाया: स्वीकृति मानदंड।

स्वीकृति मानदंड क्या है?

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

आपके लॉगिन फ़ॉर्म के लिए स्वीकृति मानदंड का उदाहरण कुछ इस तरह हो सकता है:

यह देखते हुए कि मेरा एक खाता पंजीकृत है और मैं लॉगिन फॉर्म देख रहा हूं जब मैं सही लॉगिन विवरण दर्ज करता हूं तो मुझे लॉग इन किया जाना चाहिए और मुझे होमपेज देखना चाहिए

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

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

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

अंत में, इसके प्रारूपण के आधार पर, AC आपको अधिक तार्किक मानसिकता अपनाने के लिए प्रोत्साहित करता है, और तब के उपयोग के कारण, यह सुनिश्चित करता है कि आप उपयोगकर्ता कार्यों के परिणामों के बारे में सावधानी से सोच रहे हैं। यह आपको इस बात की परवाह करता है कि कोई उपयोगकर्ता आपके ऐप का अनुभव कैसे कर सकता है, न कि केवल उन सभी ठंडी चीज़ों से जिन्हें आप जानते हैं कि आप बनाना चाहते हैं।

मैं अच्छा AC कैसे लिख सकता हूँ?

तो, आप इस सामान को लिखने पर बेच रहे हैं, लेकिन आप इसे सही कैसे करते हैं? ऊपर लॉगिन सुविधा बहुत सीधी है, लेकिन अधिक जटिल अवधारणाएं गड़बड़ एसी में परिणाम कर सकती हैं, इसलिए निम्नलिखित बातों को ध्यान में रखना महत्वपूर्ण है:

  1. उपयोगकर्ता के दृष्टिकोण से लिखें

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

2. सादगी

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

3. सादा भाषा

यह एक बिंदु 2 से संबंधित है और सीधे इसे प्रभावित करता है। सादे भाषा में AC लिखिए। इस दृष्टिकोण का एक प्रमुख लाभ यह है कि इसे गैर-तकनीकी लोग समझ सकते हैं। एक उपकरण जो किसी को एक सुविधा का वर्णन करने में सक्षम बनाता है और साथ ही कार्यान्वयन / परीक्षण को संचालित करता है, वह अमूल्य है। जटिल भाषा उससे समझौता करेगी।

4. कार्यान्वयन विस्तार से बचें

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

5. तकनीकी मत बनो

फिर, यह बिंदु ऊपर वाले से संबंधित है। एल्गोरिदम या मशीन लर्निंग का उल्लेख न करें या माइटोकॉन्ड्रिया कोशिका के बिजलीघर हैं। यह प्रासंगिक नहीं है।

क्या AC अपने आप में पर्याप्त है?

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

जब तक आप एडोब नहीं हैं, तब यह शाब्दिक रूप से कोई फर्क नहीं पड़ता कि आप क्या करते हैं, यह अभी भी बकवास होगा।

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

आप मेरे माध्यम प्रोफ़ाइल पर मेरे सामान की अधिक जानकारी पा सकते हैं और ट्विटर पर (यदि आपको पसंद हो) @lm_writing पर मेरा अनुसरण करें।