मैं वास्तविक आवश्यकताओं के सेट में UI मॉकअप से क्लाइंट को कैसे स्थानांतरित कर सकता हूं?


17

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

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

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

मैं लोगों को कैसे समझा सकता हूं कि हम यूआई मॉक-अप के आधार पर आवश्यकताओं को लॉक नहीं कर सकते हैं जो मेरे लिए कुछ कार्रवाई योग्य बना सकते हैं?

अंतिम उपयोगकर्ताओं के लिए एप्लिकेशन विकसित करने के कार्य को ठीक से निष्पादित करने के लिए आप आदर्श रूप से क्या शुरू करेंगे?


आप आवश्यकताओं के लिए कैसे पूछ रहे हैं? क्या आप केवल ग्राहक / उपयोगकर्ता के पास जा रहे हैं और कह रहे हैं कि "क्या मेरी आवश्यकताएं हैं?" या क्या आप विभिन्न तकनीकों में से किसी का उपयोग करने, कब्जा करने और आवश्यकताओं को सत्यापित करने और सत्यापित करने के लिए उपयोग कर रहे हैं?
थॉमस ओवेन्स

2
इसके लिए गैर डेवलपर्स के साथ काम करना आसान नहीं है। स्क्रीन बस एक आवेदन का वर्णन नहीं है। मेरे वर्तमान नियोक्ता को यह समझ में नहीं आता है। मेरा प्रयास प्रत्येक स्क्रीन के माध्यम से जाने और प्रत्येक आइटम के व्यवहार और "क्या अगर" के बारे में बहुत सारे प्रश्न पूछना है। इस तरह आपके पास सुविधाओं को अलग-थलग करने और ग्लॉस के तहत क्या हो सकता है डिजाइन करने में सक्षम होने की उम्मीद है।
ऋग्वेद

2
मुझे लगता है कि यह 25-टैब्ड-एक्सेल-फाइल की तुलना में बेहतर है जो कि बहुत आम है।
मॉर्गन हेर्लकर

1
यह आपके प्रश्न से स्पष्ट नहीं है कि क्या यह केवल आपके ग्राहक ने आपको दिया है या यदि आपकी टीम के किसी अन्य व्यक्ति ने आवश्यकताओं पर कब्जा करने के प्रयास के परिणामस्वरूप यह किया है। यदि यह बाद की बात है, तो आपको अपने संगठन में एक समस्या है जो बहुत गहरे-गहरे हो सकती है। यदि यह पूर्व है, तो आपको कुछ आवश्यकताओं को इकट्ठा करने की तकनीकों का अभ्यास करने की आवश्यकता होगी क्योंकि अन्य सिफारिश कर रहे हैं।
एंजेलो

1
@ उस मामले में, तब मुझे उम्मीद है कि आवश्यकताओं के लोग आपके लिए उनके पास मौजूद सभी सवालों के जवाब दे सकते हैं! हो सकता है कि वह उम्मीद करता है कि आप अनौपचारिक रूप से उसके साथ पूरी तरह से आवश्यकताएं पूरी करेंगे? यही आशावादी परिदृश्य है।
एंजेलो

जवाबों:


19

कुछ अन्य चीजें जिनकी आपको आवश्यकता हो सकती है:

  • Usecases या Workflow विवरण: सिर्फ इसलिए कि आप जानते हैं कि स्क्रीन कैसी दिखती है, क्या आप जानते हैं कि खराब इनपुट को कैसे संभाला जाता है? क्या आप जानते हैं कि सभी मामलों में स्क्रीन के बीच संक्रमण कैसे होता है? आप यहां त्रुटि हैंडलिंग भी शामिल कर सकते हैं।

  • उच्च स्तर प्रणाली विवरण: कुछ बताते हैं क्या पूरी व्यवस्था है कि इन 25 स्क्रीन के लिए कर रहे हैं, और वे क्या करते।

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

  • तकनीकी आवश्यकताएं: क्या विशिष्ट टेक्नोलाजी हैं जिनका उपयोग लाइसेंसिंग या एकीकरण कारणों के लिए किया जाना चाहिए?

  • प्रदर्शन की आवश्यकताएं: यदि कोई खोज स्क्रीन है, तो क्या कोई खोज की जा सकती है और प्रतिक्रिया कितनी तेज़ होनी चाहिए? अन्य प्रकार के कार्यों के लिए प्रतिक्रियाओं के बारे में क्या? क्या उनमें से कुछ को अतुल्यकालिक होना चाहिए (उपयोगकर्ता नौकरी को प्रस्तुत करता है और बाद में वापस आता है)?

  • सुरक्षा आवश्यकताएं: क्या एप्लिकेशन संभावित रूप से संवेदनशील / व्यक्तिगत डेटा संग्रहीत करता है और यदि हां, तो इसे सुरक्षित रखने के लिए किस प्रकार का डेटा और क्या किया जाना चाहिए? क्या आपको कुछ स्तर के अनुपालन की आवश्यकता है (जैसे क्रेडिट कार्ड से भुगतान के लिए पीसीआई अनुपालन)?

इसके अलावा, क्या कोई विशेष व्यवसाय डोमेन ज्ञान है जिसे आपको अपनी सहायता के लिए उनकी आवश्यकता हो सकती है? कुछ उद्योग जैसे बीमा, बैंकिंग, चिकित्सा स्वास्थ्य रिकॉर्ड आदि ... सभी प्रकार के जटिल व्यावसायिक तर्क हैं। इस तरह की परियोजनाओं को उस डोमेन को जानने वाले व्यवसाय विश्लेषक की मदद के बिना नहीं किया जाना चाहिए। लेकिन अगर यह जेनेरिक विजेट्स के लिए सिर्फ एक शॉपिंग कार्ट / इंफॉर्मेशन साइट है, तो आपको ऐसे टीम मेंबर की जरूरत नहीं हो सकती है।


1
मुझे नहीं पता कि आपने इसे उद्देश्य पर किया था, लेकिन यह सूची महत्व के क्रम में भी है, उपयोग के मामलों और एक उच्च स्तरीय प्रणाली विवरण के साथ (क्या उन्होंने कम से कम मॉकअप स्क्रीन लेबल किया है?) अब तक सबसे महत्वपूर्ण चीजें हैं। मुझे नहीं पता कि क्या सुरक्षा आवश्यकताओं को थापू के लिए पूछने का कोई मतलब है। यह मेरे लिए आपको एक डेवलपर के रूप में लगता है कि उनके उपयोग के मामलों का समर्थन करने के लिए सुरक्षा की क्या बेहतर आवश्यकता है, इसलिए आपको उपयोग के मामलों से सुरक्षा आवश्यकताओं पर निर्णय लेना चाहिए और फिर ग्राहक को सूचित करना चाहिए।
12

10

लोगों को यह समझने के लिए कि कार्यशील कार्यक्रम बनाने के लिए यूआई मोक्स पर्याप्त नहीं हैं:

मैं इसे एक उपमा के साथ संभालूंगा। चूंकि मैं कार नट का एक सा हूं, इसलिए मैं उस रास्ते पर जा रहा हूं।

"प्रिटेंड मुझे कारों के बारे में कुछ नहीं पता है। तुम मुझे फेरारी की कुछ तस्वीरें सौंप दो। बाहर से एक जोड़ा और कार के अंदर से एक (ड्राइवर सीट से लिया गया ताकि मैं कार के लिए नियंत्रण देख सकूं)। अब आप मुझसे पूछें। आपको एक फेरारी बनाने के लिए। मैं एक ऐसी चीज़ के साथ वापस आता हूं जो तस्वीरों की तरह दिखता है और इसमें सभी नियंत्रण हैं। दुर्भाग्य से, उन नियंत्रणों को किसी भी चीज़ से नहीं जोड़ा जाता है क्योंकि (जब से मैं कारों के बारे में कुछ भी नहीं जानता हूं) मुझे नहीं पता कि वे क्या हैं नियंत्रण करना चाहिए। मैं अनुमान भी नहीं लगा सकता क्योंकि मुझे यह भी नहीं पता है कि कारों को क्या करना चाहिए। तो फिर हमारे बीच इस तरह की बातचीत होती है:

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

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

चीजें जो मैं पूछूंगा:

सामान्य / उच्च स्तरीय समस्या वर्णन

मामलों / उपयोगकर्ता कहानियों का उपयोग करें

प्रदर्शन संबंधी जरूरतें

आवश्यक प्रौद्योगिकियों / मंच (विंडोज, लिनक्स, वेब)

सब कुछ FrustratedWithForms उसके जवाब में है


1
महान सादृश्य के लिए +1, हालांकि मुझे यकीन नहीं है कि वास्तव में ग्राहक के साथ संवाद करने का सबसे अच्छा तरीका है। मैं अपने गैर-तकनीकी मित्रों को यह बताने में मदद करूँगा कि मैं क्या करूँ, लेकिन एक ग्राहक के लिए जो थोड़ा संरक्षण कर सकता है।
झॉकिंग

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

5

विकास के प्रयास के 80% के प्रभाव के लिए कुछ 20% फ्रिंज उपयोग के मामलों की ओर जाता है। स्क्रीनशॉट आपको उपयोग के मामलों के बारे में नहीं बताएंगे, इस प्रकार आप अपने सक्रिय विकास के 80% के लिए अंधेरे में होंगे।

यह अच्छा है कि आप अधिक जानने की कोशिश कर रहे हैं और यह संवाद करने की कोशिश कर रहे हैं कि ग्राहक के लिए परियोजना की आवश्यकताओं में अधिक शामिल होना कितना महत्वपूर्ण है, हालांकि यदि वे ऐसा नहीं करते हैं तो वे विफलता के लिए परियोजना की स्थापना कर रहे हैं, और यह आपकी गलती नहीं है।

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

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


2
"आप बस एक दीवार पर जानकारी का एक टॉस नहीं कर सकते हैं और एक सॉफ्टवेयर पैकेज के रूप में अपनी सभी आशाओं और सपनों को वापस पाने की उम्मीद करते हैं" मुझे यह वाक्य बहुत पसंद है और मैं इसे चुरा रहा हूं।
HLGEM

@HLGEM, ले लो, यह तुम्हारा है!
मेपल_शॉफ्ट

4

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

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

आपको यह भी जानना होगा कि क्या प्रत्येक क्षेत्र में डेटा डाला जाना चाहिए, इस पर विशिष्ट सीमाएं हैं। क्या आवश्यक मूल्य हैं। आप उन्हें प्राप्त करने के लिए कहाँ जा रहे हैं? उन्हें कैसे अपडेट किया जाएगा? आपको यह जानना होगा कि त्रुटियों को कैसे संभालना है। आपको यह जानने की जरूरत है कि क्या डेटाबेस में ऑडिटिंग की जरूरत है या यदि आपको एक ऐतिहासिक गड़बड़ी से डेटा को फिर से बनाने में सक्षम होना चाहिए (उन pesky रिपोर्ट पर वापस)।

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


3

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


2

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


2

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

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

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

एक बार जब आप समझ जाते हैं कि उद्देश्य क्या हैं, तो आप यूआई डिजाइन मॉकअप के साथ काम करना शुरू कर सकते हैं जो आपके पास है और "रिवर्स इंजीनियर" उन मामलों और उपयोगकर्ता कहानियों का उपयोग करते हैं जो विभिन्न स्क्रीन एक साथ फिट होते हैं। उपयोगकर्ता कहानी प्रारूप शायद गैर-तकनीकी दर्शकों से निपटने के लिए अच्छी तरह से काम करेगा। का स्वरूप As a <user type>, I want to <action> so that <reason>हो रही डेवलपर्स और ग्राहकों के मामले में बाहर काम करता है / उपयोगकर्ताओं को एक ही भाषा बोलने। एक बार जब आप उपयोगकर्ता कहानियों पर एक शुरुआत प्राप्त कर सकते हैं, तो मैं विकास के लिए एक प्रोटोटाइप दृष्टिकोण अपनाऊंगा।

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

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

मैं कार्ल विएगर्स द्वारा दो पुस्तकें पढ़ने की सलाह दूंगा - सॉफ्टवेयर आवश्यकताएँ और सॉफ़्टवेयर आवश्यकताओं के बारे में अधिक । मुझे लगता है कि ये इस क्षेत्र में आवश्यकताओं इंजीनियरिंग और सर्वोत्तम प्रथाओं के साथ आपकी मदद करेंगे।


4
बस याद रखें कि यदि आप प्रोटोटाइप करते हैं, तो उपयोगकर्ता इंटरफ़ेस को कभी भी पॉलिश और समाप्त न करें, उन्हें लगता है कि अगर स्क्रीन फ़िनिशेड लगती है तो आपको कोडिंग के साथ किया जाएगा।
HLGEM

@HLGEM बहुत सही, बहुत सच। वास्तव में, मुझे पूरा यकीन है कि मैंने इस साइट पर वह सलाह दी है।
थॉमस ओवेन्स

1

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

अधिक विशेष रूप से, क्या आप मॉक-अप पर जाने के बाद भी आवेदन के बारे में चकित हैं? यदि ऐसा है, तो इसे स्वीकार करें, और यह समझाने की कोशिश करें कि आपको पता नहीं है कि प्रत्येक प्रपत्र को कौन सा डेटा प्रदर्शित करना चाहिए, या यह कहां से आएगा, क्या यह अन्य स्क्रीन या बाहरी डेटा से है?

यदि आपके पास कुछ विचार है, तो उन चीजों के उदाहरणों के साथ आने का प्रयास करें जिन्हें आप नहीं जानते कि कैसे करना है ("एक वैश्विक सूची का चयन करने के लिए टेम्पलेट्स की सूची क्या होगी या उपयोगकर्ता द्वारा उनमें से कोई भी है, या कुछ और? यदि यह है तो?" उपयोगकर्ता द्वारा नहीं, मुझे दो लोगों को इसे एक बार में संपादित करने देना चाहिए? अगर कोई व्यक्ति इसे संपादित कर रहा है तो UI क्या दिखाना चाहिए? क्या इसके लिए कोई स्क्रीन है? एक बार किसी ने किसी भी टेम्पलेट के लिए उपयोग किए जाने वाले टेम्पलेट का उपयोग किया है और फिर टेम्पलेट संपादित हो जाती है। क्या उस परिवर्तन को उस चीज़ के साथ प्रचारित किया जाना चाहिए जो उन्होंने टेम्पलेट के साथ बनाया है? ")।

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

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

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


0

आपको एप्लिकेशन में प्रत्येक क्षेत्र की सीमाएं और सीमाएं जानना आवश्यक है। उदाहरण के लिए, यदि फ़ील्ड फ़ोन नंबर है, तो क्या वे आपसे +1 को संभालने की उम्मीद करते हैं? किन क्षेत्रों की आवश्यकता है? यदि उपयोगकर्ता फ़ोन # फ़ील्ड में "abc" टाइप करता है तो वे क्या करना चाहते हैं? क्या सभी 25 स्क्रीन इस क्रम में हैं कि सभी उपयोगकर्ताओं को आगे बढ़ना चाहिए?

अन्यथा, बस सब कुछ टेक्स्ट फ़ील्ड के रूप में बनाएं और आप कर रहे हैं! एक प्रमुख गुब्बारे की तरह खत्म हो जाएगा कि शर्त करना चाहते हैं?

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.