मैं एक सिस्टम आवश्यकता दस्तावेज लिख रहा हूं और सिस्टम की प्रयोज्यता से संबंधित गैर-कार्यात्मक आवश्यकताओं को शामिल करने की आवश्यकता है, लेकिन मुझे यह व्यक्त करने का सबसे अच्छा तरीका नहीं है।औपचारिक रूप से उपयोगिता आवश्यकताओं को व्यक्त करने का सबसे अच्छा तरीका क्या है?
"सिस्टम का उपयोग करना आसान होगा" मेरे लिए थोड़ा अस्पष्ट लगता है, और टेस्टेबल नहीं। क्या कोई 'आधिकारिक' मानक/दिशानिर्देश हैं जिनका प्रयोग किसी प्रोग्राम की प्रयोज्यता से संबंधित किया जा सकता है?
आमतौर पर, हम 'उपयोग करने में आसान' की एप्लिकेशन-विशिष्ट परिभाषा को हश करने का प्रयास करते हैं। उदाहरण के लिए, हमारे वर्तमान प्रोजेक्ट के लिए, उपयोग करने में आसान मतलब है:
-5 सेकंड से अधिक समय में सिस्टम में सभी देरी एक संवाद बॉक्स उत्पन्न करेगी जो कहती है "कृपया प्रतीक्षा करें।"
- 3 क्लिक से कम में मुख्य विंडो से किसी दिए गए सिस्टम फ़ंक्शन तक पहुंचना संभव है।
- माउस के बिना, कीबोर्ड के साथ दिए गए किसी भी कार्य को पूरा करना संभव है। प्रणाली में
-सभी बटन स्थापित बटन सम्मेलन (आकार के बारे में स्थापित बटन सम्मेलन, नामकरण, स्थिति के लिए लिंक, आदि) का पालन करना होगा
-सभी स्क्रीन एक मदद बटन होगा। किसी दिए गए स्क्रीन पर प्रत्येक सहायता बटन को स्क्रीन पर प्रत्येक नियंत्रण के लिए कम से कम एक 'विषय' प्रदान करना होगा।
-etc।
इस तरह की चीजें टेस्टेबल हैं, और एक साथ ले ली गई हैं, एक 'सुंदर अच्छा' उपयोगिता मानक बनाती हैं। उस ने कहा, वास्तविक उपयोगकर्ताओं के लिए कोशिश करने के लिए कुछ विकल्प नहीं हैं।
उपयोगिता आवश्यकताएं कठिन हैं क्योंकि यह जानने का एकमात्र तरीका है कि आपका सिस्टम प्रयोग योग्य है या नहीं, असली उपयोगकर्ता इसे आज़माकर देख सकते हैं। आपकी आवश्यकताओं को पूरा करने के बाद आप कैसे जानेंगे? ऐसा करने के लिए, आपको उपयोगिता के लिए औपचारिक मीट्रिक की आवश्यकता है। उन मीट्रिक को किसी भी तरह उपयोगिता परीक्षण के परिणामों से निकाला जाना चाहिए, और यदि आप उस बिंदु पर अपनी उपयोगिता परीक्षण को सारणी देते हैं जहां आप बस मेट्रिक्स प्राप्त कर रहे हैं, तो आप इसकी उपयोगिता से वंचित हैं।
कुछ आइटम "वाई कई क्लिक के साथ एक्स करने में सक्षम होना चाहिए" या "जेड मिलीसेकंड या उससे कम में सिस्टम को जवाब देना चाहिए" उपयोगी हैं, लेकिन वे वास्तव में कार्यात्मक आवश्यकताएं हैं जो प्रयोज्यता के साथ हैं, उपयोगिता आवश्यकताओं के लिए नहीं अपने आप में। यह काफी संभव है (यदि संभव नहीं है) कि आप ऐसी प्रणाली को डिजाइन और कार्यान्वित कर सकते हैं जो ऐसी सभी औपचारिक आवश्यकताओं को पूरा करता है और अभी भी उपयोगकर्ताओं के लिए निराशाजनक है। फिर, जानने का एकमात्र तरीका उपयोगिता परीक्षण के माध्यम से है।
ठीक है, 'सिस्टम का उपयोग करना आसान होगा' वास्तव में ऐसे दस्तावेज हैं जो डिजाइनरों और डेवलपर्स दोनों को निराश करते हैं, तो देखते हैं कि हम उससे थोड़ा बेहतर कर सकते हैं या नहीं? :)
साथ शुरू करने के लिए, आपको बैठकर यह पता लगाना उपयोगी हो सकता है कि इच्छित उपयोगकर्ता कौन है। उन्हें एक पृष्ठभूमि दें, उन्हें थोड़ा रंग दें, फिर उन्हें अपने कल्पना किए गए एप्लिकेशन पर भेजें और यह पता लगाने और समझें कि वे व्यक्तियों के साथ कैसे बातचीत करना चाहते हैं।
याद रखें, विभिन्न उपयोगकर्ता उपयोगिता के विभिन्न पहलुओं के बारे में चिंतित हैं।आपको लगता है कि यदि आप एप्लिकेशन का उपयोग कर रहे थे तो कहानी पथ पर ध्यान केंद्रित न करें।
अगला साइट को उपयोगिता घटकों में तोड़ने में मददगार हो सकता है। क्या इसमें बहुत सारी तस्वीरें हैं? यदि हां, तो उपयोगकर्ता को बहुत सारी तस्वीरें पेश करने का सबसे अच्छा तरीका क्या है। क्या इसमें गहरा घोंसला वाला मेनू संरचना है? क्या आपके उपयोगकर्ताओं को अपने रास्ते पर नेविगेट करने में मदद करने के लिए साइट्रेट की तुलना में बेहतर तरीका हो सकता है? उपयोगिता डिजाइन पैटर आपको यहां मदद करेंगे। उपयोगिता के लिए डिजाइन पैटर्न के लिए एक अच्छा संसाधन here और here पाया जा सकता है। डिजाइन पैटर्न अच्छे हैं क्योंकि वे स्पष्ट रूप से शामिल सभी को समझाते हैं कि कुछ कार्यक्षमता कैसे काम करनी चाहिए।
प्रयोज्यता के साथ संयोजन में अभिगम्यता पर विचार करने के लिए एक पल लें। जावास्क्रिप्ट बंद होने के साथ साइट कैसे काम करती है हमेशा शुरू करने के लिए एक बहुत ही अच्छी जगह होती है और डेवलपर्स के लिए एक बड़ी मदद हो सकती है जो अपने डिजाइनर स्टिक को देखने के बहुत थक गए हैं, फिर भी एक पृष्ठ पर लिंक <a> लिंक सबमिट करने की आवश्यकता होगी प्रपत्र।
याद रखें, प्रयोज्यता स्पष्टता के बारे में है और यह सिस्टम बनाने वाले लोगों के लिए स्पष्ट संचार से शुरू होती है। यदि आप जो चाहते हैं उसके बारे में स्पष्ट रूप से बात नहीं कर सकते हैं तो आप डेवलपर्स को कुछ कार्यात्मक बनाने की उम्मीद कैसे करते हैं? यदि आपको करना है तो पेपर प्रोटोटाइप पर अतिरिक्त समय लें।
मेरा उत्तर आपके लिए बहुत अधिक उपयोग करने के लिए केंद्रित बहुत छोटा 'वेब' हो सकता है, लेकिन मुझे उम्मीद है कि यह मेरे ranting के बीच कुछ उपयोगी tidbits प्रदान करता है।
मेट्रिक्स & उपयोगकेस।
हमारे पास कई अलग-अलग व्यक्ति हैं जो हमारे विभिन्न ग्राहक प्रकारों को समाहित करते हैं।
हमारे पास उपयोगकर्ता पावरुसर (जॉर्ज, वह एक बेवकूफ, विश्वविद्यालय का प्रकार है), गैर-तकनीकी व्यक्ति (फ्रैंक, जो शायद ही कभी कैलकुलेटर का उपयोग कर सकता है) और बीच में कोई (सुसी, वह जानता है कि वेब सर्फ कैसे करें और तकनीकी सहायता से बात कर सकते हैं लेकिन उससे पूछें कि क्या emacs है)।
उस आधार पर हम कह:
अब, मीट्रिक के लिए, हम भी प्रयोज्य अध्ययन के दिशा निर्देशों, जैसे 10 लोगों में से 8 मदद को देखे बिना फ़ीचर वाई का उपयोग या 30 सेकंड के साथ यह करने के लिए सक्षम होने के लिए सक्षम होना चाहिए।
वे वास्तव में व्यक्तिपरक हैं, लेकिन यह आपको सही दिशा में जाने में मदद कर सकता है। इसके अलावा, यह आपको गैर-डेवलपर प्रकारों से बात करने में मदद कर सकता है जो "बस इसे काम करना चाहते हैं और आसान हो"।
सॉफ्टवेयर लेखों पर जोएल को पढ़ने में भी कोई दिक्कत नहीं होगी।
एक आवश्यकता दस्तावेज में उपयोगिता आवश्यकताओं को शामिल करने का सबसे स्पष्ट तरीका यह है कि: मुझे बहुत सारे स्क्रीन मॉक-अप (और प्रदर्शन किए गए कार्यों के "प्रवाह" से कनेक्ट करें, उदाहरण के लिए तीर बिंदु से छवि 1 पर प्रासंगिक आइटम पर छवि 1 पर एक आइटम)। अगर लोग वास्तव में देखते हैं कि कुछ कैसे काम करना है, तो समझना आसान है और व्याख्या के लिए कम जगह छोड़ देता है।
@ [alex77]: यदि आप इसे माप नहीं सकते हैं या इसका परीक्षण नहीं कर सकते हैं, तो यह एक आवश्यकता नहीं है। –
आपको बहुत धन्यवाद –