निर्णय का आधार
तकनीक चुनने से पहले दिखने वाला व्यवहार लिखें: व्यक्ति, शुरुआती स्थिति, कार्रवाई और जाँचा जा सकने वाला परिणाम। परिणाम बदलने वाले अधिकार और अपवाद जोड़ें।
एक व्यावहारिक उदाहरण
काल्पनिक खर्च टूल में कर्मचारी रसीद देता है, प्रबंधक मंजूर करता या कारण सहित लौटाता है और वित्त स्वीकृत मद निकालता है। अपठनीय रसीद, अनुपस्थित प्रबंधक और मंजूरी के बाद राशि बदलना तय करें।
अभिनय करके दिखने वाला उदाहरण
काल्पनिक मान लें: यात्रा रसीद डालना, परियोजना चुनना और जमा करना। प्रबंधक केवल अनुमत रिकॉर्ड देखे। लौटाने में कारण और संपादन खुले; मंजूरी संस्करण स्थिर करे। बाद का सुधार नया संस्करण, नई मंजूरी या अस्वीकार है, तय करें। तकनीक से पहले कार्ड से मामला चल सके।
नियम, पसंद और अनुमान अलग
“केवल वित्त स्वीकृत खर्च निकाले” अधिकार है; “बटन ऊपर दाएँ”, सुझाव; “शीट चाहिए”, प्राप्त प्रक्रिया जाने बिना अनुमान। डिजाइन वादा बदले बिना सुधरता है। नियम स्रोत और स्पष्ट करने वाला लिखें। बाध्यता के लिए अधिकृत पाठ या योग्य व्याख्या लें, डेवलपर का अंदाजा नहीं।
सभी भूमिकाओं से समीक्षा
जमा करने वाला, समीक्षक और वित्त एक मामला देखें: टूटा अपलोड, अनुपस्थिति, दोहराया निर्यात और सुधरा बिल। जरूरी निर्णय जोड़ें, पसंद खुली रखें। प्रदर्शन और सुरक्षित डेटा लिखें। मंजूर आवश्यकताओं का संस्करण रखें। स्पष्टता व्यवसाय फैसले गढ़े बिना बनाना और जाँचना संभव करती है।
विकल्पों का आकलन
छोटी कहानी संदर्भ, रेखाचित्र संवाद और स्वीकृति उदाहरण सीमाएँ बताते हैं। जरूरत अनुसार मिलाएँ; बड़ा दस्तावेज़ अद्यतन फैसलों का विकल्प नहीं।
योजना कहाँ टूटती है
व्यवसाय नियम समझाने के लिए डेटाबेस तालिकाएँ न लिखें। “तेज” या “आसान” के साथ काम और जाँच का मानदंड चाहिए। जरूरी व्यवहार और डिजाइन सुझाव अलग करें, मतभेद सुलझाने वाला तय करें।
काम शुरू कराने से पहले
क्या दूसरा व्यक्ति सफलता और विफलता दिखा सकता है? भूमिकाएँ स्पष्ट हैं? उदाहरण साझा करना सुरक्षित है? आवश्यकताएँ और अनिश्चितताएँ MVP चर्चा में लाएँ।