व्यावसायिक नियमों को कैसे दस्तावेज़ित करें

12

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

documentation business-rules

— मारो
स्रोत

"औपचारिक" शायद ही कभी "सबसे अच्छा तरीका" होता है। आपका शीर्षक मुझे भ्रमित कर रहा है :

— जोप

मैंने इसे बदल दिया है, मुझे आशा है कि कम भ्रमित है :)

— मारो

तकनीकी डॉक्टर या कार्यात्मक डॉक्टर? इस दस्तावेज़ को कौन पढ़ने जा रहा है?

— लाईव

1

व्यावसायिक नियमों के लिए मुझे लगता है कि @ जोप्पे ने यूएमएल की ओर इशारा किया, हम सभी सोच रहे थे।

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

ऐसे चित्र हैं जो विभिन्न स्तरों पर व्यवसाय के महान साक्षात्कार भी करते हैं:

राज्य मशीन आरेख यदि राज्यों के किसी भी प्रकार का दस्तावेज है।
गतिविधि आरेख । कॉम्प्लेक्स यूज केस के लिए आपको विवरण में गहराई तक जाने की आवश्यकता हो सकती है। विवरण का स्तर आपके ऊपर है और इस बात पर निर्भर करता है कि दस्तावेज़ीकरण कौन पढ़ रहा है। यह व्यवसाय-संबंधी दस्तावेज़ नहीं लग सकता है, लेकिन विवरण के सही स्तर के साथ ऐसा हो सकता है।

बस एक सलाह, प्रत्येक उपयोग मामले के लिए एक कोड निर्दिष्ट करें (जैसे: यूसी -1 , यूसी-एन )। यूआई प्रलेखन के दौरान ये बाद में उपयोगी होंगे।

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

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

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

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

अंत में ध्यान रखें कि आप किसे संबोधित कर रहे हैं।

तकनीशियन : आप विवरणों में गहराई तक जा सकते हैं और तकनीकी का उपयोग कर सकते हैं।
टेक्निशियन नहीं : तकनीकी से बचें (न तो अपसैट से संबंधित है और न ही कोड)। स्पष्ट और सरल होने का प्रयास करें और ग्राहक द्वारा उपयोग किए जाने वाले समान शब्दों / शब्दों का उपयोग करें। ऐसे समझें कि आपको प्रोग्रामिंग का कोई पता नहीं था।

— Laiv
स्रोत

5

प्रलेखन अक्सर उपयोग के मामलों और अन्य गद्य रूपों में किया जाता है। इसके अलावा यूएमएल आरेख और अन्य चित्रमय रूपों के लिए यह अत्यंत उपयोगी हो सकता है जो आपको उच्च स्तर पर अवलोकन देते हैं और पृष्ठों और पृष्ठों को पढ़ने की तुलना में कम समय में समझने में आसान होते हैं।

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

— मैनफ़्रेड मोजर
स्रोत

4

संभवतः सबसे आम रूप है यूज़ केस । आप उन्हें स्क्रीन मॉक-अप और विवरण के साथ पूरक कर सकते हैं।

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

— Joppe
स्रोत

2

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

— मॉर्गन हेरलॉकर
स्रोत

0

मैं केवल उपयोग के मामले और यूआई डिज़ाइन से व्यावसायिक नियमों को संदर्भित करके सिस्टम विनिर्देश से व्यावसायिक नियमों को कड़ाई से अलग करने की सलाह देता हूं। मेरी पसंदीदा तकनीक है: - एक स्प्रेडशीट में पहचाने गए व्यावसायिक नियमों की एक सूची है। - सिस्टम डिज़ाइन में, केस स्पेसिफिकेशन, यूज़र स्टोरीज़ या जो भी हो, का उपयोग करें, बस "उपयोगकर्ता व्यावसायिक नियम BR012 में निर्दिष्ट जानकारी दर्ज करता है", "सिस्टम व्यवसाय नियम BR510 में निर्दिष्ट कुल राशि की गणना करता है"। मैं इस लेख की सिफारिश करता हूं http://www.allaboutrequirements.com/business-rules/

— डाक्टर
स्रोत

-1

दृश्य स्टूडियो कोड और प्लांट UML प्लगइन का उपयोग करके UML आरेख बनाने की कोशिश करें

— नील
स्रोत