616

EN + हिं Medium

GB What is 'requirements risk assessment' and how does it differ from general project risk assessment?

IN 'आवश्यकताएँ जोखिम मूल्यांकन' क्या है और यह सामान्य परियोजना जोखिम मूल्यांकन से कैसे भिन्न है?

A

Requirements risk assessment is identical to general project risk assessment with no meaningful distinction आवश्यकताएँ जोखिम मूल्यांकन बिना किसी सार्थक अंतर के सामान्य परियोजना जोखिम मूल्यांकन के समान है

B

Requirements risk assessment specifically evaluates risks inherent to the requirements themselves: ambiguity risk (multiple interpretations possible), volatility risk (likely to change), feasibility risk (may not be technically achievable), and conflict risk (incompatible with other requirements) — distinct from general project risks like schedule or resource availability आवश्यकताएँ जोखिम मूल्यांकन विशेष रूप से स्वयं आवश्यकताओं में निहित जोखिमों का मूल्यांकन करता है: अस्पष्टता जोखिम (कई व्याख्याएँ संभव), अस्थिरता जोखिम (परिवर्तन की संभावना), व्यवहार्यता जोखिम (तकनीकी रूप से प्राप्त नहीं हो सकता), और संघर्ष जोखिम (अन्य आवश्यकताओं के साथ असंगत) - अनुसूची या संसाधन उपलब्धता जैसे सामान्य परियोजना जोखिमों से अलग

C

Requirements risk assessment only considers financial risks associated with requirement implementation आवश्यकताएँ जोखिम मूल्यांकन केवल आवश्यकता कार्यान्वयन से जुड़े वित्तीय जोखिमों पर विचार करता है

D

Requirements risk is always zero once a requirement has been formally documented and signed off एक बार किसी आवश्यकता को औपचारिक रूप से प्रलेखित और हस्ताक्षरित कर दिए जाने के बाद आवश्यकताओं का जोखिम हमेशा शून्य होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Specific requirements risk indicators: requirements written by a single stakeholder without cross-validation (high conflict risk), requirements describing emerging technology with no proven implementations (high feasibility risk), requirements in domains with pending regulatory changes (high volatility risk). Identifying these early allows targeted mitigation — prototyping for feasibility risk, multi-stakeholder review for conflict risk — rather than discovering them as project delays later.

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

617

EN + हिं Easy

GB What is the 'requirements engineering maturity model' and what distinguishes ad-hoc elicitation from systematic elicitation?

IN 'आवश्यकताओं इंजीनियरिंग परिपक्वता मॉडल' क्या है और क्या तदर्थ उद्दीपन को व्यवस्थित उद्दीपन से अलग करता है?

A

Maturity is determined solely by the number of pages in the requirements document परिपक्वता केवल आवश्यकता दस्तावेज़ में पृष्ठों की संख्या से निर्धारित होती है

B

REMM describes progression from ad-hoc (informal conversations, no defined process, requirements captured inconsistently) to systematic (defined elicitation techniques selected per stakeholder type, structured documentation templates, formal review and validation processes, traceability maintained throughout lifecycle) आरईएमएम तदर्थ (अनौपचारिक बातचीत, कोई परिभाषित प्रक्रिया नहीं, असंगत रूप से पकड़ी गई आवश्यकताएं) से लेकर व्यवस्थित (प्रति हितधारक प्रकार के अनुसार चयनित परिभाषित एलिसिटेशन तकनीक, संरचित दस्तावेज टेम्पलेट, औपचारिक समीक्षा और सत्यापन प्रक्रियाएं, पूरे जीवन चक्र में अनुरेखण बनाए रखने की क्षमता) तक की प्रगति का वर्णन करता है।

C

Ad-hoc elicitation is always superior to systematic elicitation because it is faster तदर्थ उद्दीपन हमेशा व्यवस्थित उद्दीपन से बेहतर होता है क्योंकि यह तेज़ होता है

D

REMM only applies to government software projects with formal procurement requirements REMM केवल औपचारिक खरीद आवश्यकताओं वाली सरकारी सॉफ्टवेयर परियोजनाओं पर लागू होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Ad-hoc organisations capture requirements inconsistently — sometimes a Slack message, sometimes an email, sometimes verbal agreement with no record. This creates traceability gaps and forgotten requirements. Systematic organisations have defined templates (Volere shell), trained elicitation practitioners, structured review checkpoints, and tooling (Jira, DOORS) maintaining bidirectional traceability — enabling consistent quality regardless of which analyst handles which requirement.

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

618

EN + हिं Medium

GB What is 'requirements completeness criterion' and why is achieving 100% completeness theoretically impossible for complex systems?

IN 'आवश्यकताएँ पूर्णता मानदंड' क्या है और जटिल प्रणालियों के लिए 100% पूर्णता प्राप्त करना सैद्धांतिक रूप से असंभव क्यों है?

A

100% completeness is always achievable with sufficient stakeholder interviews and time investment पर्याप्त हितधारक साक्षात्कार और समय निवेश के साथ 100% पूर्णता हमेशा प्राप्त की जा सकती है

B

Completeness means all necessary requirements (functional, non-functional, edge cases, error conditions) are specified — for complex systems it's theoretically impossible because: emergent requirements only become apparent through usage, unknown unknowns cannot be elicited in advance, and the cost of specifying every conceivable edge case exceeds its value पूर्णता का मतलब है कि सभी आवश्यक आवश्यकताएं (कार्यात्मक, गैर-कार्यात्मक, किनारे के मामले, त्रुटि की स्थिति) निर्दिष्ट हैं - जटिल प्रणालियों के लिए यह सैद्धांतिक रूप से असंभव है क्योंकि: आकस्मिक आवश्यकताएं केवल उपयोग के माध्यम से स्पष्ट हो जाती हैं, अज्ञात अज्ञात को पहले से प्राप्त नहीं किया जा सकता है, और प्रत्येक कल्पनीय किनारे के मामले को निर्दिष्ट करने की लागत इसके मूल्य से अधिक है

C

Completeness is only impossible for safety-critical systems; commercial software can always achieve it सुरक्षा-महत्वपूर्ण प्रणालियों के लिए पूर्णता केवल असंभव है; व्यावसायिक सॉफ़्टवेयर इसे हमेशा प्राप्त कर सकता है

D

Completeness criterion was abandoned by IEEE 830 in its most recent revision आईईईई 830 द्वारा अपने सबसे हालिया संशोधन में पूर्णता मानदंड को छोड़ दिया गया था

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This is one of the fundamental arguments for iterative/agile approaches: rather than pursuing impossible upfront completeness, deliver incrementally and let usage reveal previously unknown requirements. Practical completeness is a cost-benefit judgment: specify enough to proceed safely, accept that some requirements will emerge during development, and build in mechanisms (change control, feedback loops) to incorporate them efficiently rather than treating their discovery as project failure.

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

619

EN + हिं Easy

GB What is 'requirements engineering for AI/ML systems' and what unique challenge does non-deterministic behaviour introduce?

IN 'एआई/एमएल सिस्टम के लिए आवश्यकताएँ इंजीनियरिंग' क्या है और गैर-नियतात्मक व्यवहार कौन सी अनोखी चुनौती पेश करता है?

A

AI/ML requirements engineering is identical to traditional software requirements with no meaningful differences एआई/एमएल आवश्यकताएं इंजीनियरिंग बिना किसी सार्थक अंतर के पारंपरिक सॉफ्टवेयर आवश्यकताओं के समान है

B

ML systems exhibit probabilistic, data-dependent behaviour that traditional deterministic acceptance criteria ('given input X, output shall be Y') cannot capture — requirements must instead specify acceptable performance distributions (accuracy thresholds, false positive/negative rate bounds), training data quality requirements, and fairness/bias constraints across demographic groups एमएल सिस्टम संभाव्य, डेटा-निर्भर व्यवहार प्रदर्शित करते हैं जिसे पारंपरिक नियतात्मक स्वीकृति मानदंड ('दिए गए इनपुट एक्स, आउटपुट वाई होगा') पर कब्जा नहीं किया जा सकता है - आवश्यकताओं को इसके बजाय स्वीकार्य प्रदर्शन वितरण (सटीकता सीमा, गलत सकारात्मक / नकारात्मक दर सीमाएं), प्रशिक्षण डेटा गुणवत्ता आवश्यकताओं और जनसांख्यिकीय समूहों में निष्पक्षता / पूर्वाग्रह बाधाओं को निर्दिष्ट करना होगा।

C

AI/ML systems require no formal requirements because the model learns requirements automatically from data एआई/एमएल सिस्टम को किसी औपचारिक आवश्यकता की आवश्यकता नहीं होती है क्योंकि मॉडल डेटा से आवश्यकताओं को स्वचालित रूप से सीखता है

D

ML requirements engineering only applies to image recognition systems, not other AI applications एमएल आवश्यकताएँ इंजीनियरिंग केवल छवि पहचान प्रणालियों पर लागू होती है, अन्य एआई अनुप्रयोगों पर नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Traditional requirement: 'the system shall calculate tax correctly' is deterministic and verifiable exactly. ML requirement: 'the fraud detection model shall achieve 95% precision and 90% recall on the validation set, with no demographic group's false positive rate exceeding 1.5x the overall rate' — this acknowledges inherent uncertainty while still establishing measurable, testable bounds. The shift from deterministic correctness to statistical performance bounds is fundamental to ML requirements engineering.

व्याख्या (हिन्दी) पारंपरिक आवश्यकता: 'प्रणाली सही ढंग से कर की गणना करेगी' निश्चित और सटीक रूप से सत्यापन योग्य है। एमएल आवश्यकता: 'धोखाधड़ी का पता लगाने वाला मॉडल सत्यापन सेट पर 95% परिशुद्धता और 90% रिकॉल प्राप्त करेगा, जिसमें किसी भी जनसांख्यिकीय समूह की झूठी सकारात्मक दर समग्र दर 1.5x से अधिक नहीं होगी' - यह मापने योग्य, परीक्षण योग्य सीमाएं स्थापित करते समय अंतर्निहित अनिश्चितता को स्वीकार करता है। नियतात्मक शुद्धता से सांख्यिकीय प्रदर्शन सीमा में बदलाव एमएल आवश्यकताओं इंजीनियरिंग के लिए मौलिक है।

620

EN + हिं Easy

GB What is 'requirements engineering for regulatory compliance' and what specific traceability burden does it impose beyond typical requirements?

IN 'नियामक अनुपालन के लिए आवश्यकताएँ इंजीनियरिंग' क्या है और यह सामान्य आवश्यकताओं से परे कौन सा विशिष्ट पता लगाने की क्षमता का बोझ डालती है?

A

Regulatory compliance requirements need no special handling different from any other requirement category विनियामक अनुपालन आवश्यकताओं को किसी अन्य आवश्यकता श्रेणी से अलग किसी विशेष प्रबंधन की आवश्यकता नहीं है

B

Compliance requirements (GDPR, HIPAA, PCI-DSS) require demonstrable evidence that each regulatory clause maps to specific system requirements, which map to design elements, code modules, and verification tests — auditors must be able to trace 'GDPR Article 17 (right to erasure)' through this entire chain to verify compliance, far beyond typical functional requirement traceability अनुपालन आवश्यकताओं (जीडीपीआर, एचआईपीएए, पीसीआई-डीएसएस) के लिए स्पष्ट साक्ष्य की आवश्यकता होती है कि प्रत्येक नियामक खंड विशिष्ट सिस्टम आवश्यकताओं को मैप करता है, जो तत्वों, कोड मॉड्यूल और सत्यापन परीक्षणों को डिजाइन करने के लिए मैप करता है - लेखा परीक्षकों को अनुपालन को सत्यापित करने के लिए इस पूरी श्रृंखला के माध्यम से 'जीडीपीआर अनुच्छेद 17 (मिटाने का अधिकार)' का पता लगाने में सक्षम होना चाहिए, जो सामान्य कार्यात्मक आवश्यकता ट्रैसेबिलिटी से परे है।

C

Regulatory compliance is achieved automatically by purchasing compliance certification software अनुपालन प्रमाणन सॉफ़्टवेयर खरीदकर नियामक अनुपालन स्वचालित रूप से प्राप्त किया जाता है

D

Compliance traceability is only required for healthcare software; other regulated industries are exempt अनुपालन ट्रैसेबिलिटी केवल स्वास्थ्य देखभाल सॉफ़्टवेयर के लिए आवश्यक है; अन्य विनियमित उद्योगों को छूट है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) GDPR audits ask: 'show me exactly how a user's erasure request propagates through your systems.' This requires traceability from the legal text, through the specific requirement ('the system shall permanently delete user PII from all data stores within 30 days of a verified erasure request'), to the design (which services are involved), to the code (the deletion implementation), to test evidence (proof the deletion actually works across all stores including backups and logs). Gaps anywhere in this chain represent compliance risk and potential fines.

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

621

EN + हिं Easy

GB What is 'requirements engineering tool selection criteria' and what capability distinguishes enterprise tools (DOORS, Polarion) from lightweight tools (Jira)?

IN 'आवश्यकताएँ इंजीनियरिंग उपकरण चयन मानदंड' क्या है और कौन सी क्षमता उद्यम उपकरण (डोर, पोलारियन) को हल्के उपकरण (जीरा) से अलग करती है?

A

Enterprise and lightweight tools provide identical functionality; the only difference is licensing cost एंटरप्राइज़ और हल्के उपकरण समान कार्यक्षमता प्रदान करते हैं; एकमात्र अंतर लाइसेंसिंग लागत का है

B

Enterprise RE tools provide formal traceability matrices, baseline/version comparison, regulatory compliance reporting templates, and bidirectional impact analysis across thousands of requirements — capabilities needed for safety-critical/regulated domains; lightweight tools optimise for fast iteration and collaboration in less formally regulated contexts एंटरप्राइज़ आरई उपकरण औपचारिक ट्रैसेबिलिटी मैट्रिक्स, बेसलाइन/संस्करण तुलना, विनियामक अनुपालन रिपोर्टिंग टेम्पलेट्स और हजारों आवश्यकताओं में द्विदिश प्रभाव विश्लेषण प्रदान करते हैं - सुरक्षा-महत्वपूर्ण/विनियमित डोमेन के लिए आवश्यक क्षमताएं; हल्के उपकरण कम औपचारिक रूप से विनियमित संदर्भों में तेज़ पुनरावृत्ति और सहयोग के लिए अनुकूलित होते हैं

C

Lightweight tools always produce better requirements quality than enterprise tools regardless of context संदर्भ की परवाह किए बिना हल्के उपकरण हमेशा एंटरप्राइज़ टूल की तुलना में बेहतर आवश्यकताओं की गुणवत्ता का उत्पादन करते हैं

D

Tool selection has no measurable impact on requirements engineering quality or efficiency उपकरण चयन का आवश्यकताओं की इंजीनियरिंग गुणवत्ता या दक्षता पर कोई मापने योग्य प्रभाव नहीं पड़ता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A medical device manufacturer needs DOORS' formal baseline comparison ('show me every requirement changed between v2.1 and v2.2, and which design/test artefacts need re-review') for FDA submission evidence. A startup building a consumer app needs Jira's speed and developer-friendliness more than formal traceability. Choosing enterprise tooling for a low-regulation context adds unnecessary overhead; choosing lightweight tooling for regulated domains creates compliance risk and audit failures.

व्याख्या (हिन्दी) एक चिकित्सा उपकरण निर्माता को FDA सबमिशन साक्ष्य के लिए DOORS की औपचारिक बेसलाइन तुलना की आवश्यकता होती है ('मुझे v2.1 और v2.2 के बीच बदली गई हर आवश्यकता दिखाएं, और कौन से डिज़ाइन/परीक्षण कलाकृतियों की पुन: समीक्षा की आवश्यकता है')। उपभोक्ता ऐप बनाने वाले स्टार्टअप को औपचारिक ट्रैसेबिलिटी से अधिक जीरा की गति और डेवलपर-मित्रता की आवश्यकता होती है। कम-विनियमन संदर्भ के लिए एंटरप्राइज़ टूलींग का चयन करना अनावश्यक ओवरहेड जोड़ता है; विनियमित डोमेन के लिए हल्के टूलींग चुनने से अनुपालन जोखिम और ऑडिट विफलताएं पैदा होती हैं।

622

EN + हिं Medium

GB What is 'requirements pattern' and how does using established requirement patterns reduce common specification errors?

IN 'आवश्यकताएँ पैटर्न' क्या है और स्थापित आवश्यकता पैटर्न का उपयोग सामान्य विनिर्देश त्रुटियों को कैसे कम करता है?

A

Requirements patterns are visual design templates for user interface mockups only आवश्यकताएँ पैटर्न केवल उपयोगकर्ता इंटरफ़ेस मॉकअप के लिए विज़ुअल डिज़ाइन टेम्पलेट हैं

B

Requirements patterns (Withall's catalogue) provide proven templates for commonly recurring requirement types (e.g., 'the system shall validate <data> against <rule> and shall <action> if invalid') — using established patterns reduces errors by ensuring all necessary clauses (error handling, boundary conditions, audit logging) are systematically included rather than ad-hoc and incomplete आवश्यकताएँ पैटर्न (विथॉल का कैटलॉग) आम तौर पर आवर्ती आवश्यकता प्रकारों के लिए सिद्ध टेम्पलेट प्रदान करता है (उदाहरण के लिए, 'सिस्टम इसके विरुद्ध मान्य करेगा और यदि अमान्य है तो करेगा') - स्थापित पैटर्न का उपयोग करके सभी आवश्यक खंड (त्रुटि प्रबंधन, सीमा की स्थिति, ऑडिट लॉगिंग) को व्यवस्थित रूप से शामिल करना सुनिश्चित करके त्रुटियों को कम किया जाता है, बजाय तदर्थ और अपूर्ण के।

C

Requirements patterns are only applicable to database-related requirements and cannot be used elsewhere आवश्यकताएँ पैटर्न केवल डेटाबेस-संबंधित आवश्यकताओं पर लागू होते हैं और अन्यत्र उपयोग नहीं किए जा सकते

D

Using requirements patterns guarantees the resulting system will have zero defects आवश्यकताओं के पैटर्न का उपयोग यह गारंटी देता है कि परिणामी प्रणाली में शून्य दोष होंगे

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A validation requirement pattern systematically prompts the author: what's the valid range? what happens on invalid input (reject, default, error message)? should the attempt be logged? is there a maximum retry count? Writing this requirement from scratch, an analyst might forget the error path entirely — a common gap discovered only during testing. Patterns encode accumulated experience about what 'complete' looks like for each requirement category.

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

623

EN + हिं Medium

GB What is 'goal-oriented requirements engineering' (GORE) and how does the KAOS method structure goal decomposition?

IN 'लक्ष्य-उन्मुख आवश्यकताएँ इंजीनियरिंग' (GORE) क्या है और KAOS विधि संरचना लक्ष्य अपघटन कैसे करती है?

A

GORE only applies to sales and marketing software where business goals are quantifiable GORE केवल बिक्री और विपणन सॉफ्टवेयर पर लागू होता है जहां व्यावसायिक लक्ष्य मापे जा सकते हैं

B

GORE starts from high-level organisational goals and systematically refines them into operational requirements through AND/OR decomposition trees — KAOS (Knowledge Acquisition in autOmated Specification) formally models goals, agents (who is responsible), obstacles (what could prevent goal achievement), and the requirements needed to overcome obstacles GORE उच्च-स्तरीय संगठनात्मक लक्ष्यों से शुरू होता है और उन्हें AND/OR अपघटन वृक्षों के माध्यम से परिचालन आवश्यकताओं में व्यवस्थित रूप से परिष्कृत करता है - KAOS (स्वचालित विशिष्टता में ज्ञान अधिग्रहण) औपचारिक रूप से लक्ष्यों, एजेंटों (जो जिम्मेदार है), बाधाओं (जो लक्ष्य उपलब्धि को रोक सकता है), और बाधाओं को दूर करने के लिए आवश्यक आवश्यकताओं को मॉडल करता है।

C

GORE eliminates the need for stakeholder interviews because goals are derived purely from financial models GORE हितधारकों के साक्षात्कार की आवश्यकता को समाप्त कर देता है क्योंकि लक्ष्य पूरी तरह से वित्तीय मॉडल से प्राप्त होते हैं

D

KAOS method is identical to use case modelling with no meaningful distinction केएओएस विधि बिना किसी सार्थक अंतर के केस मॉडलिंग के उपयोग के समान है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) GORE addresses the disconnect where requirements satisfy stated needs but miss the underlying business goal. Starting from 'increase customer retention by 15%' (goal), AND-decomposition produces sub-goals ('reduce response time complaints', 'improve product reliability'), which decompose into specific requirements. KAOS additionally models obstacles ('users abandon carts due to slow checkout') and derives requirements specifically to overcome them ('checkout shall complete within 3 seconds for 95% of transactions') — directly linking every requirement back to its business rationale.

व्याख्या (हिन्दी) GORE उस वियोग को संबोधित करता है जहाँ आवश्यकताएँ बताई गई आवश्यकताओं को पूरा करती हैं लेकिन अंतर्निहित व्यावसायिक लक्ष्य से चूक जाती हैं। 'ग्राहक प्रतिधारण में 15% की वृद्धि' (लक्ष्य) से शुरू होकर, AND-विघटन उप-लक्ष्यों ('प्रतिक्रिया समय की शिकायतों को कम करना', 'उत्पाद विश्वसनीयता में सुधार') का निर्माण करता है, जो विशिष्ट आवश्यकताओं में विघटित हो जाते हैं। केएओएस अतिरिक्त रूप से बाधाओं को मॉडल करता है ('धीमे चेकआउट के कारण उपयोगकर्ता कार्ट छोड़ देते हैं') और उन्हें दूर करने के लिए विशेष रूप से आवश्यकताओं को प्राप्त करता है ('95% लेनदेन के लिए चेकआउट 3 सेकंड के भीतर पूरा हो जाएगा') - प्रत्येक आवश्यकता को सीधे उसके व्यावसायिक तर्क से जोड़ता है।

624

EN + हिं Easy

GB What is 'event-driven architecture' (EDA) and what decoupling benefit does it provide over direct service-to-service calls?

IN 'इवेंट-संचालित आर्किटेक्चर' (ईडीए) क्या है और यह सीधे सेवा-से-सेवा कॉल पर क्या डिकम्प्लिंग लाभ प्रदान करता है?

A

EDA requires all services to share a single database to coordinate events ईडीए को घटनाओं के समन्वय के लिए सभी सेवाओं को एक ही डेटाबेस साझा करने की आवश्यकता है

B

EDA has services publish events to a broker (Kafka, RabbitMQ) without knowing which services consume them — producers and consumers are decoupled in time (consumer can be offline) and space (producer doesn't know consumer's address), enabling independent scaling and evolution of each service ईडीए के पास ब्रोकर (काफ्का, रैबिटएमक्यू) को इवेंट प्रकाशित करने वाली सेवाएं हैं, बिना यह जाने कि कौन सी सेवाएं उनका उपभोग करती हैं - उत्पादकों और उपभोक्ताओं को समय (उपभोक्ता ऑफ़लाइन हो सकता है) और स्थान (निर्माता को उपभोक्ता का पता नहीं पता है) में अलग किया जाता है, जिससे प्रत्येक सेवा की स्वतंत्र स्केलिंग और विकास संभव हो जाता है।

C

EDA is only suitable for systems with fewer than 5 microservices due to broker overhead ब्रोकर ओवरहेड के कारण ईडीए केवल 5 से कम माइक्रोसर्विसेज वाले सिस्टम के लिए उपयुक्त है

D

Event-driven architecture eliminates the need for any error handling since events are guaranteed delivery इवेंट-संचालित आर्किटेक्चर किसी भी त्रुटि प्रबंधन की आवश्यकता को समाप्त कर देता है क्योंकि इवेंट की डिलीवरी की गारंटी होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) In direct calls, Service A must know Service B's address and B must be available when A calls — tight coupling. In EDA, Service A publishes 'OrderPlaced' to a topic without knowing who cares. Service B (inventory), C (shipping), D (analytics) can each independently subscribe, be added later without changing A, and process the event whenever they're ready (even if currently down, with message persistence). This temporal and spatial decoupling is EDA's core architectural value.

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

625

EN + हिं Easy

GB What is the 'CQRS' (Command Query Responsibility Segregation) pattern and what specific scaling problem does it solve?

IN 'सीक्यूआरएस' (कमांड क्वेरी रिस्पॉन्सिबिलिटी सेग्रीगेशन) पैटर्न क्या है और यह किस विशिष्ट स्केलिंग समस्या का समाधान करता है?

A

CQRS requires using two different programming languages for read and write operations CQRS को पढ़ने और लिखने के संचालन के लिए दो अलग-अलग प्रोग्रामिंग भाषाओं का उपयोग करने की आवश्यकता होती है

B

CQRS separates the data model and code path for writes (commands) from reads (queries) — solving the problem where read-heavy and write-heavy workloads have conflicting optimisation needs (writes need normalisation/consistency, reads need denormalisation/speed), allowing each to scale and be optimised independently CQRS डेटा मॉडल और कोड पथ को रीड्स (क्वेरीज़) से लिखने (कमांड) के लिए अलग करता है - उस समस्या को हल करना जहां रीड-हेवी और राइट-हैवी वर्कलोड में विरोधाभासी अनुकूलन आवश्यकताएं होती हैं (राइट को सामान्यीकरण/स्थिरता की आवश्यकता होती है, रीड्स को असामान्यकरण/गति की आवश्यकता होती है), प्रत्येक को स्केल करने और स्वतंत्र रूप से अनुकूलित करने की अनुमति देता है

C

CQRS is only applicable to systems using NoSQL databases; SQL systems cannot implement it CQRS केवल NoSQL डेटाबेस का उपयोग करने वाले सिस्टम पर लागू होता है; SQL सिस्टम इसे कार्यान्वित नहीं कर सकता

D

CQRS eliminates the need for a database entirely by storing all data in application memory CQRS एप्लिकेशन मेमोरी में सभी डेटा को संग्रहीत करके डेटाबेस की आवश्यकता को पूरी तरह से समाप्त कर देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) An e-commerce system might have 1000 reads (browsing) for every 1 write (purchase). Without CQRS, the same normalised schema serves both — reads require expensive joins, writes are simple. CQRS creates a separate denormalised read model (optimised for the exact queries the UI needs, updated asynchronously from the write model) — reads become fast key-value lookups while writes maintain transactional integrity in the normalised command model.

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

626

EN + हिं Easy

GB What is 'domain-driven design' (DDD) and what does a 'bounded context' specifically prevent?

IN 'डोमेन-संचालित डिज़ाइन' (डीडीडी) क्या है और 'सीमाबद्ध संदर्भ' विशेष रूप से क्या रोकता है?

A

Bounded context limits the number of developers who can work on a project simultaneously बंधा हुआ संदर्भ उन डेवलपर्स की संख्या को सीमित करता है जो किसी प्रोजेक्ट पर एक साथ काम कर सकते हैं

B

DDD models software around business domains and their terminology; a bounded context defines the scope within which a domain model and its terminology (ubiquitous language) are consistent — it prevents the 'model conflation' problem where the same term (e.g., 'Customer') means different things in different parts of the system, causing confusion and design errors डीडीडी व्यावसायिक डोमेन और उनकी शब्दावली के आसपास सॉफ्टवेयर मॉडल करता है; एक सीमित संदर्भ उस दायरे को परिभाषित करता है जिसके भीतर एक डोमेन मॉडल और उसकी शब्दावली (सर्वव्यापी भाषा) सुसंगत होती है - यह 'मॉडल कन्फ़्लेशन' समस्या को रोकता है जहां एक ही शब्द (उदाहरण के लिए, 'ग्राहक') का अर्थ सिस्टम के विभिन्न हिस्सों में अलग-अलग चीजें हैं, जिससे भ्रम और डिजाइन त्रुटियां होती हैं।

C

Bounded context requires all microservices to share the exact same data model बंधे हुए संदर्भ के लिए सभी माइक्रोसर्विसेज को बिल्कुल समान डेटा मॉडल साझा करने की आवश्यकता होती है

D

DDD is only applicable to financial software systems, not other domains डीडीडी केवल वित्तीय सॉफ्टवेयर सिस्टम पर लागू है, अन्य डोमेन पर नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) In a retail system, 'Customer' in the Sales context means someone with purchase history and loyalty points; 'Customer' in the Support context means someone with ticket history and SLA tier; 'Customer' in Billing means someone with payment methods and invoices. Trying to build one unified 'Customer' class for all three creates an unwieldy God object. Bounded contexts allow each subsystem its own 'Customer' model, integrated through translation at context boundaries rather than forcing artificial unification.

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

627

EN + हिं Hard

GB What is 'idempotency' in distributed system design and why is it specifically critical for payment processing APIs?

IN वितरित सिस्टम डिज़ाइन में 'इडेम्पोटेंसी' क्या है और यह भुगतान प्रसंस्करण एपीआई के लिए विशेष रूप से महत्वपूर्ण क्यों है?

A

Idempotency means an operation always returns the same response time regardless of load इडेम्पोटेंसी का मतलब है कि एक ऑपरेशन लोड की परवाह किए बिना हमेशा एक ही प्रतिक्रिया समय देता है

B

An idempotent operation produces the same result whether executed once or multiple times — critical for payments because network failures cause clients to retry requests uncertain whether the original succeeded; without idempotency, retries could charge a customer multiple times for one purchase एक इडेम्पोटेंट ऑपरेशन एक ही परिणाम उत्पन्न करता है चाहे उसे एक बार या कई बार निष्पादित किया जाए - भुगतान के लिए महत्वपूर्ण है क्योंकि नेटवर्क विफलताओं के कारण ग्राहकों को अनुरोधों को फिर से प्रयास करना पड़ता है, यह अनिश्चित होता है कि मूल सफल हुआ या नहीं; निष्क्रियता के बिना, पुनर्प्रयास एक ग्राहक से एक खरीदारी के लिए कई बार शुल्क ले सकता है

C

Idempotency only applies to read operations; write operations cannot be made idempotent इडेम्पोटेंसी केवल पढ़ने के संचालन पर लागू होती है; लेखन संचालन को निष्क्रिय नहीं बनाया जा सकता

D

Idempotency is guaranteed automatically by all HTTP POST requests without additional implementation अतिरिक्त कार्यान्वयन के बिना सभी HTTP POST अनुरोधों द्वारा स्वचालित रूप से निष्क्रियता की गारंटी दी जाती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Payment APIs implement idempotency keys: the client generates a unique key per logical transaction and includes it with every retry of the same request. The server checks if it has already processed that key — if so, it returns the cached result without re-executing the charge. This solves the 'did my request succeed?' uncertainty inherent to distributed systems where network timeouts don't tell you whether the server actually processed the request before the connection dropped.

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

628

EN + हिं Easy

GB What is 'circuit breaker pattern' in microservices and what three states does it cycle through?

IN माइक्रोसर्विसेज में 'सर्किट ब्रेकर पैटर्न' क्या है और यह किन तीन अवस्थाओं से होकर गुजरता है?

A

Circuit breaker patterns only apply to electrical hardware components, not software systems सर्किट ब्रेकर पैटर्न केवल विद्युत हार्डवेयर घटकों पर लागू होते हैं, सॉफ़्टवेयर सिस्टम पर नहीं

B

Circuit breaker prevents cascading failures by monitoring calls to a downstream service and 'tripping' when failure rate exceeds a threshold — it cycles through: Closed (normal operation, calls pass through), Open (failures detected, calls fail immediately without attempting the downstream service), Half-Open (after a timeout, test calls are allowed to check if the service has recovered) सर्किट ब्रेकर डाउनस्ट्रीम सेवा पर कॉल की निगरानी करके और विफलता दर एक सीमा से अधिक होने पर 'ट्रिपिंग' करके कैस्केडिंग विफलताओं को रोकता है - यह चक्रित होता है: बंद (सामान्य ऑपरेशन, कॉल पास हो जाती है), ओपन (विफलताओं का पता चला, डाउनस्ट्रीम सेवा का प्रयास किए बिना कॉल तुरंत विफल हो जाती है), हाफ-ओपन (टाइमआउट के बाद, परीक्षण कॉल को यह जांचने की अनुमति दी जाती है कि सेवा ठीक हो गई है या नहीं)

C

Circuit breakers are only relevant for systems using synchronous REST APIs, not asynchronous messaging सर्किट ब्रेकर केवल सिंक्रोनस REST API का उपयोग करने वाले सिस्टम के लिए प्रासंगिक हैं, एसिंक्रोनस मैसेजिंग के लिए नहीं

D

The circuit breaker pattern guarantees zero downtime for the protected downstream service सर्किट ब्रेकर पैटर्न संरक्षित डाउनस्ट्रीम सेवा के लिए शून्य डाउनटाइम की गारंटी देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Without circuit breakers, when Service B becomes slow/unresponsive, Service A keeps calling it, exhausting A's thread pool waiting for timeouts — A itself becomes unresponsive, and this cascades to A's callers (Service Z calling A also exhausts its resources). The circuit breaker's Open state fails fast (immediate error, no wasted waiting), protecting Service A's resources and giving Service B breathing room to recover without continued load.

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

629

EN + हिं Easy

GB What is 'saga pattern' in distributed transactions and what consistency model does it provide compared to ACID transactions?

IN वितरित लेनदेन में 'सागा पैटर्न' क्या है और यह ACID लेनदेन की तुलना में कौन सा स्थिरता मॉडल प्रदान करता है?

A

Saga pattern provides identical strong consistency guarantees to traditional ACID database transactions सागा पैटर्न पारंपरिक ACID डेटाबेस लेनदेन के लिए समान मजबूत स्थिरता की गारंटी प्रदान करता है

B

Saga pattern coordinates a sequence of local transactions across multiple services, each with a compensating transaction that undoes its effect if a later step fails — providing eventual consistency rather than ACID's immediate consistency, since there's no global lock across all services during the saga's execution सागा पैटर्न कई सेवाओं में स्थानीय लेनदेन के अनुक्रम को समन्वयित करता है, प्रत्येक एक क्षतिपूर्ति लेनदेन के साथ जो बाद के चरण विफल होने पर इसके प्रभाव को कम कर देता है - एसीआईडी की तत्काल स्थिरता के बजाय अंततः स्थिरता प्रदान करता है, क्योंकि गाथा के निष्पादन के दौरान सभी सेवाओं में कोई वैश्विक लॉक नहीं होता है

C

Saga pattern eliminates the need for any error handling in distributed transaction scenarios सागा पैटर्न वितरित लेनदेन परिदृश्यों में किसी भी त्रुटि प्रबंधन की आवश्यकता को समाप्त करता है

D

Saga pattern only works with synchronous communication and cannot use asynchronous messaging सागा पैटर्न केवल सिंक्रोनस संचार के साथ काम करता है और एसिंक्रोनस मैसेजिंग का उपयोग नहीं कर सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A travel booking saga: reserve flight (T1), reserve hotel (T2), charge payment (T3). If T3 fails after T1 and T2 succeeded, compensating transactions run: cancel hotel (C2), cancel flight (C1) — undoing the partial work. This is fundamentally different from ACID's all-or-nothing atomicity (impossible across service boundaries without distributed locks that kill scalability) — the system passes through temporarily inconsistent intermediate states before reaching eventual consistency.

व्याख्या (हिन्दी) एक यात्रा बुकिंग गाथा: आरक्षित उड़ान (T1), आरक्षित होटल (T2), शुल्क भुगतान (T3)। यदि T1 और T2 के सफल होने के बाद T3 विफल हो जाता है, तो क्षतिपूर्ति लेनदेन चलता है: होटल रद्द करें (C2), उड़ान रद्द करें (C1) - आंशिक कार्य को पूर्ववत करना। यह मूल रूप से ACID की ऑल-ऑर-नथिंग एटोमिसिटी (स्केलेबिलिटी को खत्म करने वाले वितरित लॉक के बिना सेवा सीमाओं के पार असंभव) से अलग है - सिस्टम अंतिम स्थिरता तक पहुंचने से पहले अस्थायी रूप से असंगत मध्यवर्ती राज्यों से गुजरता है।

630

EN + हिं Easy

GB What is 'anti-corruption layer' (ACL) in DDD and what specific integration problem does it solve?

IN डीडीडी में 'भ्रष्टाचार विरोधी परत' (एसीएल) क्या है और यह किस विशिष्ट एकीकरण समस्या का समाधान करती है?

A

ACL is a security layer that prevents malware from corrupting application data ACL एक सुरक्षा परत है जो मैलवेयर को एप्लिकेशन डेटा को दूषित करने से रोकती है

B

ACL is a translation layer isolating your domain model from an external system's (often legacy or third-party) different and potentially poor model — solving the problem where direct integration would force your clean domain model to absorb the external system's inconsistencies, naming conflicts, or design flaws एसीएल एक अनुवाद परत है जो आपके डोमेन मॉडल को बाहरी सिस्टम (अक्सर विरासत या तीसरे पक्ष) के अलग और संभावित रूप से खराब मॉडल से अलग करती है - उस समस्या को हल करना जहां प्रत्यक्ष एकीकरण आपके स्वच्छ डोमेन मॉडल को बाहरी सिस्टम की विसंगतियों, नामकरण संघर्षों, या डिज़ाइन त्रुटियों को अवशोषित करने के लिए मजबूर करेगा।

C

Anti-corruption layers are only needed when integrating with databases, not with APIs भ्रष्टाचार-रोधी परतों की आवश्यकता केवल डेटाबेस के साथ एकीकृत करते समय होती है, एपीआई के साथ नहीं

D

ACL eliminates the need for any data validation when receiving external data बाहरी डेटा प्राप्त करते समय एसीएल किसी भी डेटा सत्यापन की आवश्यकता को समाप्त कर देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Integrating with a 1990s mainframe inventory system that uses cryptic field names, inconsistent date formats, and a fundamentally different conceptual model than your clean modern domain would, without an ACL, pollute your domain with the legacy system's quirks. The ACL translates: legacy 'ITM_STAT=A' becomes your domain's clean 'ItemStatus.Available' enum, isolating your bounded context's model purity from the external system's accidental complexity.

व्याख्या (हिन्दी) 1990 के दशक के मेनफ्रेम इन्वेंट्री सिस्टम के साथ एकीकरण, जो आपके स्वच्छ आधुनिक डोमेन की तुलना में गुप्त फ़ील्ड नाम, असंगत दिनांक प्रारूप और मौलिक रूप से भिन्न वैचारिक मॉडल का उपयोग करता है, एसीएल के बिना, आपके डोमेन को विरासत प्रणाली की विचित्रताओं से प्रदूषित कर देगा। ACL अनुवाद करता है: विरासत 'ITM_STAT=A' आपके डोमेन का स्वच्छ 'ItemStatus.Available' एनम बन जाता है, जो आपके बंधे हुए संदर्भ की मॉडल शुद्धता को बाहरी सिस्टम की आकस्मिक जटिलता से अलग कर देता है।

Software Engineering — MCQ Practice