एक व्यवसाय विश्लेषक के रूप में आवश्यकताओं को कैसे व्यवस्थित करें

व्यावसायिक आवश्यकता एक औपचारिक दस्तावेज़ है जो किसी परियोजना या उत्पाद के लिए हितधारकों की ज़रूरतों को दर्शाता है। व्यावसायिक आवश्यकताओं को प्रस्तुत करने का कोई एक मानक प्रारूप नहीं है, लेकिन प्रत्येक संस्करण में उत्पाद या परियोजना को पर्याप्त विस्तार से शामिल किया जाना चाहिए ताकि उस पर चर्चा, विश्लेषण, दस्तावेज़ीकरण और सत्यापन किया जा सके।

किसी व्यावसायिक आवश्यकता को निम्नलिखित में से किसी भी तरीके से प्रस्तुत किया जा सकता है:

• एक तालिका या स्प्रेडशीट
• एक आरेख (कार्यप्रवाह)
• एक ग्राफ
• एक मॉडल (इकाई-संबंध आरेख)
• एक प्रोटोटाइप या सिमुलेशन
• एक संरचित वाक्य या पाठ टेम्पलेट

व्यावसायिक आवश्यकता को कैसे व्यवस्थित और प्रस्तुत करें

नीचे आवश्यकताओं को लिखने और व्यवस्थित करने के चरण दिए गए हैं। व्यापार विश्लेषक.

चरण 1) आवश्यकताओं को वर्गीकृत करें।

• प्रत्येक आवश्यकता को उसके संबंधित वर्ग में रखें।
• तकनीकी हितधारकों को तकनीकी आवश्यकता श्रेणी दिखाई देनी चाहिए, और गैर-तकनीकी हितधारकों को व्यावसायिक या सामान्य आवश्यकता श्रेणी दिखाई देनी चाहिए।
• प्रत्येक संगठन को यह तय करना चाहिए कि कौन सी श्रेणियां उसके अपने मानकों के अनुरूप हैं।
• वर्गीकरण आवश्यकता के प्रकार के आधार पर भी किया जा सकता है - कार्यात्मक बनाम व्यावसायिक - हालांकि यह विभाजन हर परियोजना पर लागू नहीं होता है।

चरण 2) आवश्यकताओं की व्यवस्था करें.
आवश्यकताओं को एकत्रित करें और उन्हें तार्किक क्रम में व्यवस्थित करें ताकि हितधारक दस्तावेज़ को आसानी से देख सकें और छूटी हुई चीज़ों को पहचान सकें।

चरण 3) एक सूची तैयार करें.
उन हितधारकों के आधार पर आवश्यकताओं की एक समीक्षा सूची तैयार करें जिन्हें उन पर हस्ताक्षर करने की आवश्यकता है।

उदाहरण के लिए, तकनीकी पृष्ठभूमि वाला कोई हितधारक उत्पाद के केवल तकनीकी पहलू में ही रुचि रखेगा।

चरण 4) अद्वितीय पहचानकर्ताओं का उपयोग करें.
If tracएक दूसरे के लिए आवश्यकताओं को पूरा करना मुश्किल है, इसलिए अद्वितीय पहचानकर्ताओं का उपयोग करें। tracक्षमता को आसान बनाना।

चरण 5) हितधारकों द्वारा पसंदीदा विधि से आवश्यकताओं को प्रस्तुत करें।
आपको अलग-अलग हितधारकों के लिए एक ही आवश्यकता को अलग-अलग प्रारूपों में प्रस्तुत करने की आवश्यकता हो सकती है - एक को ग्राफिकल दृश्य पसंद हो सकता है, जबकि दूसरे को संरचित वाक्य पसंद हो सकते हैं।

चरण 6) विषय-सूची तैयार करें।
सभी आवश्यकताओं के लिए एक विषय-सूची तैयार करें। इससे हितधारकों को सहायता मिलेगी। tracऔर उन्हें जल्दी से ढूंढ लें।

चरण 7) व्यवसाय विश्लेषण उपकरण का उपयोग करें.
उपयोग व्यवसाय विश्लेषण उपकरण जो रिलीज के दौरान आवश्यकताओं को लगातार प्रस्तुत करने और वर्गीकृत करने में मदद करते हैं।

चरण 8) प्रक्रिया प्रवाह के अनुसार आवश्यकता दस्तावेजों को व्यवस्थित करें।
दस्तावेज़ से अनावश्यक आवश्यकताओं को हटा दें और शेष आवश्यकताओं को उनके द्वारा समर्थित प्रक्रिया प्रवाह के अनुसार व्यवस्थित करें।

चरण 9) आवश्यकताओं का मानचित्र बनाएं.
आपके द्वारा एकत्रित की गई प्रत्येक आवश्यकता को प्रक्रिया प्रवाह के एक विशिष्ट चरण से जोड़ें ताकि समीक्षक आवश्यकता को उस कार्यप्रवाह से जोड़ सकें जिसका वह समर्थन करती है।

चरण 10) तालिका एवं बुलेट पॉइंट का उपयोग करें।
जटिल आवश्यकताओं को प्रस्तुत करने के लिए तालिकाओं का उपयोग करें और प्रत्येक आवश्यकता के प्रमुख पहलुओं को उजागर करने के लिए बुलेट पॉइंट्स का उपयोग करें।

व्यावसायिक आवश्यकता दस्तावेज़ लिखने और प्रस्तुत करने के लिए उपयोगी सुझाव

बेहतर प्रस्तुति के लिए और tracव्यावसायिक आवश्यकताओं के संबंध में, निम्नलिखित सुझाव किसी भी बिजनेस एनालिस्ट (बीए) के लिए सहायक हैं।

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

व्यावसायिक आवश्यकताओं को विज़ुअलाइज़ करने की लोकप्रिय तकनीकें

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

• व्यावसायिक प्रक्रिया मॉडल और संकेतन (बीपीएमएन): यह आरेख पूल, लेन, गेटवे और इवेंट्स के साथ संपूर्ण व्यावसायिक प्रक्रियाओं को दर्शाता है। बीपीएमएन यह दिखाने के लिए आदर्श है कि कौन क्या करता है और कब करता है।
• यूज़ केस डायग्राम और Descriptआयन: एक्टर-सिस्टम इंटरैक्शन और प्रत्येक एक्टर द्वारा अपेक्षित परिणामों को कैप्चर करें। फीचर-आधारित बैकलॉग के लिए उपयुक्त।
• स्वीकृति मानदंडों के साथ उपयोगकर्ता कहानियां: “एक … के रूप में मैं … चाहता हूँ ताकि …” जैसे संक्षिप्त कथन, जिन्हें Given-When-Then मानदंड के साथ जोड़ा जाता है। एजाइल टीमों में यह डिफ़ॉल्ट प्रारूप है।
• वायरफ्रेम और मॉकअप: कम या मध्यम फ़िडेलिटी वाली स्क्रीनें निर्मित Figmaबलसामिक, या Axure जो गैर-तकनीकी हितधारकों के लिए यूआई आवश्यकताओं को मूर्त रूप देते हैं।
• एंटिटी रिलेशनशिप डायग्राम (ईआरडी): समाधान में संग्रहित किए जाने वाले डेटा एंटिटी और उनके बीच के संबंधों को दर्शाएं — यह रिपोर्टिंग और एकीकरण आवश्यकताओं के लिए महत्वपूर्ण है।
• डेटा प्रवाह आरेख (डीएफडी): Tracयह समझने के लिए कि डेटा प्रक्रियाओं, भंडारों और बाहरी तत्वों के माध्यम से कैसे आगे बढ़ता है, विशेष रूप से विश्लेषण या एकीकरण परियोजनाओं में।

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

व्यावसायिक आवश्यकताओं के दस्तावेज़ों को व्यवस्थित करने के लिए सामान्य उपकरण

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

• जीरा के साथ कॉन्फ्लुएंस: एजाइल टीमों के लिए डिफ़ॉल्ट संयोजन। आवश्यकताएँ जीरा में एपिक्स और स्टोरीज़ के रूप में मौजूद होती हैं, जिन्हें कॉन्फ्लुएंस पेजों द्वारा समर्थित किया जाता है जिनमें बीआरडी विवरण और आरेख होते हैं।
• जामा कनेक्ट: आवश्यकताओं के प्रबंधन, बेसलाइनिंग और लाइव कार्यान्वयन पर केंद्रित एंटरप्राइज प्लेटफॉर्म tracचिकित्सा उपकरण और एयरोस्पेस जैसे विनियमित उद्योगों के लिए योग्यता।
• IBM Engineering Requirements प्रबंधन द्वार: रक्षा, ऑटोमोटिव और सुरक्षा-महत्वपूर्ण प्रणालियों में लंबे समय से उपयोग किया जाने वाला उपकरण, जहां हर आवश्यकता पूरी होनी चाहिए। tracसक्षम.
• Modern Requirements एसटी Azure देवोप्स: का विस्तार Azure वर्क आइटम से सीधे समीक्षा, अनुमोदन, बेसलाइनिंग और वर्ड-शैली बीआरडी निर्यात के साथ डेवऑप्स।
• Miro or Lucidchart: व्हाइटबोर्ड और डायग्रामिंग टूल्स का उपयोग बीपीएमएन, ईआरडी, यूजर जर्नी और वर्कशॉप नोट्स का मसौदा तैयार करने के लिए किया जाता है, जो बाद में औपचारिक बीआरडी में शामिल होते हैं।
• बलसामिक और Figma: वायरफ्रेम और प्रोटोटाइप टूल जो यूआई आवश्यकताओं को लिखित रूप में प्रस्तुत करने के बजाय दृश्य रूप में रखते हैं।

परियोजना के आकार और ऑडिट आवश्यकताओं के अनुरूप टूलसेट चुनें। छोटी परियोजनाओं के लिए कॉन्फ्लुएंस और जीरा से शुरुआत की जा सकती है, जबकि विनियमित कार्यक्रमों के लिए आमतौर पर जामा या डीओआरएस की आवश्यकता होती है। tracयोग्यता लेखापरीक्षा।

व्यावसायिक आवश्यकताओं को प्रस्तुत करते समय होने वाली सामान्य गलतियाँ

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

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

Revप्रत्येक हितधारक सत्र से पहले इस सूची के आधार पर बीआरडी की समीक्षा करने से उन अधिकांश मुद्दों का पता चल जाता है जो बाद के चरणों में पुन: कार्य का कारण बनते हैं।

अक्सर पूछे जाने वाले प्रश्न