Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2686
EN + हिं Easy
GB What is the 'product owner anti-pattern' of being a 'proxy product owner' and what organisational dysfunction does it indicate?
IN 'प्रॉक्सी उत्पाद स्वामी' होने का 'उत्पाद स्वामी विरोधी पैटर्न' क्या है और यह किस संगठनात्मक शिथिलता का संकेत देता है?
A
A proxy product owner is an AI system that automatically makes all backlog prioritisation decisions प्रॉक्सी उत्पाद स्वामी एक एआई प्रणाली है जो स्वचालित रूप से सभी बैकलॉग प्राथमिकता निर्णय लेती है
B
A proxy product owner relays decisions from a 'real' decision-maker (often a business stakeholder unwilling to engage directly with the team) without having genuine authority to make prioritisation trade-offs — this indicates the organisation hasn't genuinely empowered the product owner role, causing decision delays and information loss through the relay chain एक प्रॉक्सी उत्पाद स्वामी प्राथमिकता निर्धारण व्यापार-बंद करने के लिए वास्तविक अधिकार के बिना एक 'वास्तविक' निर्णय-निर्माता (अक्सर एक व्यावसायिक हितधारक टीम के साथ सीधे जुड़ने के लिए अनिच्छुक होता है) के निर्णयों को रिले करता है - यह इंगित करता है कि संगठन ने उत्पाद स्वामी की भूमिका को वास्तव में सशक्त नहीं किया है, जिससे निर्णय में देरी होती है और रिले श्रृंखला के माध्यम से जानकारी की हानि होती है।
C
Proxy product owners are an officially recommended Scrum practice for large enterprises प्रॉक्सी उत्पाद स्वामी बड़े उद्यमों के लिए आधिकारिक तौर पर अनुशंसित स्क्रम अभ्यास हैं
D
Having a proxy product owner always improves decision-making speed and quality प्रॉक्सी उत्पाद स्वामी होने से निर्णय लेने की गति और गुणवत्ता में हमेशा सुधार होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Scrum Guide requires the Product Owner to have real authority over the backlog. A proxy PO ('let me check with the VP and get back to you') reintroduces the latency and information distortion that direct stakeholder engagement was meant to eliminate. The team's questions get answered days later, often inaccurately relayed. This pattern reveals an organisation that has adopted Scrum's ceremonies without addressing the underlying authority and accountability structure required for it to function effectively.
व्याख्या (हिन्दी) स्क्रम गाइड के लिए उत्पाद स्वामी के पास बैकलॉग पर वास्तविक अधिकार होना आवश्यक है। एक प्रॉक्सी पीओ ('मुझे वीपी से जांच करने दें और आपसे संपर्क करने दें') विलंबता और सूचना विकृति को फिर से प्रस्तुत करता है जिसे प्रत्यक्ष हितधारक जुड़ाव को खत्म करना था। टीम के सवालों का जवाब कई दिनों बाद मिलता है, अक्सर गलत तरीके से बताया जाता है। यह पैटर्न एक ऐसे संगठन का खुलासा करता है जिसने प्रभावी ढंग से कार्य करने के लिए आवश्यक अंतर्निहित प्राधिकरण और जवाबदेही संरचना को संबोधित किए बिना स्क्रम के समारोहों को अपनाया है।
2687
EN + हिं Medium
GB What is 'non-functional requirement decomposition' and why is 'the system shall be secure' an inadequate requirement statement?
IN 'गैर-कार्यात्मक आवश्यकता अपघटन' क्या है और 'सिस्टम सुरक्षित रहेगा' एक अपर्याप्त आवश्यकता विवरण क्यों है?
A
This statement is adequate because security is a well-understood universal concept यह कथन पर्याप्त है क्योंकि सुरक्षा एक अच्छी तरह से समझी जाने वाली सार्वभौमिक अवधारणा है
B
NFR decomposition breaks abstract quality goals into specific, measurable sub-requirements; 'secure' is inadequate because it doesn't specify against which threats, to what assurance level, or how compliance would be verified — proper decomposition specifies: authentication method, encryption standards, access control model, audit logging requirements, each independently testable एनएफआर अपघटन अमूर्त गुणवत्ता लक्ष्यों को विशिष्ट, मापने योग्य उप-आवश्यकताओं में तोड़ देता है; 'सुरक्षित' अपर्याप्त है क्योंकि यह निर्दिष्ट नहीं करता है कि किस खतरे के खिलाफ, किस आश्वासन स्तर पर, या अनुपालन कैसे सत्यापित किया जाएगा - उचित अपघटन निर्दिष्ट करता है: प्रमाणीकरण विधि, एन्क्रिप्शन मानक, एक्सेस नियंत्रण मॉडल, ऑडिट लॉगिंग आवश्यकताएं, प्रत्येक स्वतंत्र रूप से परीक्षण योग्य
C
Security requirements should never be decomposed because doing so reduces overall system security सुरक्षा आवश्यकताओं को कभी भी विघटित नहीं किया जाना चाहिए क्योंकि ऐसा करने से समग्र सिस्टम सुरक्षा कम हो जाती है
D
NFR decomposition is only necessary for performance requirements, not security requirements एनएफआर अपघटन केवल प्रदर्शन आवश्यकताओं के लिए आवश्यक है, सुरक्षा आवश्यकताओं के लिए नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) 'Secure' is unverifiable as stated — what test would confirm it? Decomposition produces testable requirements: 'all data at rest shall be encrypted with AES-256', 'authentication shall require multi-factor verification for admin accounts', 'all access attempts shall be logged with timestamp and outcome'. Each is independently verifiable through specific tests, unlike the vague parent statement.
व्याख्या (हिन्दी) जैसा कहा गया है 'सुरक्षित' अप्राप्य है - कौन सा परीक्षण इसकी पुष्टि करेगा? अपघटन परीक्षण योग्य आवश्यकताओं का उत्पादन करता है: 'बाकी सभी डेटा को एईएस -256 के साथ एन्क्रिप्ट किया जाएगा', 'प्रमाणीकरण के लिए व्यवस्थापक खातों के लिए बहु-कारक सत्यापन की आवश्यकता होगी', 'सभी एक्सेस प्रयासों को टाइमस्टैम्प और परिणाम के साथ लॉग किया जाएगा'। अस्पष्ट मूल कथन के विपरीत, प्रत्येक को विशिष्ट परीक्षणों के माध्यम से स्वतंत्र रूप से सत्यापित किया जा सकता है।
2688
EN + हिं Easy
GB What is the 'requirements elicitation interview bias' problem and what techniques mitigate the 'leading question' bias specifically?
IN 'आवश्यकताएँ प्राप्त साक्षात्कार पूर्वाग्रह' समस्या क्या है और कौन सी तकनीकें विशेष रूप से 'अग्रणी प्रश्न' पूर्वाग्रह को कम करती हैं?
A
Interview bias does not affect requirements quality if the interviewer is a senior business analyst यदि साक्षात्कारकर्ता एक वरिष्ठ व्यवसाय विश्लेषक है तो साक्षात्कार पूर्वाग्रह आवश्यकताओं की गुणवत्ता को प्रभावित नहीं करता है
B
Interview bias occurs when the interviewer's questions, framing, or assumptions inadvertently shape stakeholder answers — leading questions ('don't you think the system should have feature X?') are mitigated by open-ended questioning techniques, asking stakeholders to describe current workflows before discussing solutions, and triangulating answers across multiple independent stakeholders साक्षात्कार पूर्वाग्रह तब होता है जब साक्षात्कारकर्ता के प्रश्न, फ़्रेमिंग, या धारणाएँ अनजाने में हितधारक उत्तरों को आकार देते हैं - प्रमुख प्रश्न ('क्या आपको नहीं लगता कि सिस्टम में फ़ीचर एक्स होना चाहिए?') को ओपन-एंडेड प्रश्न तकनीकों द्वारा कम किया जाता है, समाधानों पर चर्चा करने से पहले हितधारकों से वर्तमान वर्कफ़्लो का वर्णन करने के लिए कहा जाता है, और कई स्वतंत्र हितधारकों के बीच उत्तरों को त्रिकोणित किया जाता है।
C
Interview bias only affects technical stakeholders, not business stakeholders साक्षात्कार पूर्वाग्रह केवल तकनीकी हितधारकों को प्रभावित करता है, व्यावसायिक हितधारकों को नहीं
D
The best way to eliminate interview bias is to only interview one stakeholder per requirement साक्षात्कार पूर्वाग्रह को खत्म करने का सबसे अच्छा तरीका यह है कि आवश्यकता के अनुसार केवल एक हितधारक का साक्षात्कार लिया जाए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Leading questions plant the interviewer's assumption in the answer: stakeholders often agree with suggested features even if they wouldn't have thought of them independently, creating false validation. Open-ended techniques ('walk me through how you currently handle X') reveal actual needs without contaminating them with the interviewer's preconceptions. Triangulation across multiple stakeholders catches individual interview distortions through pattern consistency.
व्याख्या (हिन्दी) प्रमुख प्रश्न उत्तर में साक्षात्कारकर्ता की धारणा को स्थापित करते हैं: हितधारक अक्सर सुझाई गई विशेषताओं से सहमत होते हैं, भले ही उन्होंने उनके बारे में स्वतंत्र रूप से नहीं सोचा हो, जिससे गलत सत्यापन होता है। ओपन-एंडेड तकनीकें ('मुझे बताएं कि आप वर्तमान में एक्स को कैसे संभालते हैं') साक्षात्कारकर्ता की पूर्व धारणाओं से दूषित हुए बिना वास्तविक जरूरतों को प्रकट करती हैं। कई हितधारकों के बीच त्रिकोणीकरण पैटर्न स्थिरता के माध्यम से व्यक्तिगत साक्षात्कार विकृतियों को पकड़ता है।
2689
EN + हिं Easy
GB What is 'requirements negotiation' (Win-Win) and what specific outcome distinguishes it from simple requirements prioritisation?
IN 'आवश्यकताओं पर बातचीत' (विन-विन) क्या है और कौन सा विशिष्ट परिणाम इसे साधारण आवश्यकताओं की प्राथमिकता से अलग करता है?
A
Requirements negotiation and prioritisation are identical activities with no meaningful distinction आवश्यकताओं पर बातचीत और प्राथमिकता बिना किसी सार्थक अंतर के समान गतिविधियां हैं
B
Win-Win negotiation seeks mutually satisfactory agreement among conflicting stakeholders, identifying creative compromises that satisfy multiple parties' underlying interests; prioritisation simply orders requirements by importance without resolving the underlying conflicts between stakeholder interests विन-विन वार्ता परस्पर विरोधी हितधारकों के बीच पारस्परिक रूप से संतोषजनक समझौते की तलाश करती है, ऐसे रचनात्मक समझौतों की पहचान करती है जो कई पक्षों के अंतर्निहित हितों को संतुष्ट करते हैं; प्राथमिकताकरण केवल हितधारक हितों के बीच अंतर्निहित संघर्षों को हल किए बिना आवश्यकताओं को महत्व देता है
C
Win-Win negotiation always means each stakeholder gets exactly 50% of their original request विन-विन बातचीत का हमेशा मतलब होता है कि प्रत्येक हितधारक को उनके मूल अनुरोध का ठीक 50% मिलता है
D
Win-Win negotiation is only applicable when there are exactly two conflicting stakeholders विन-विन वार्ता केवल तभी लागू होती है जब वास्तव में दो परस्पर विरोधी हितधारक हों
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Boehm's Win-Win Spiral approach: rather than simply ranking 'security' above 'usability' (prioritisation), negotiation explores why each stakeholder wants what they want and seeks solutions satisfying both underlying interests — perhaps biometric authentication satisfies both security (strong authentication) and usability (no password to remember). This creative problem-solving produces better outcomes than zero-sum prioritisation where one party's win is another's loss.
व्याख्या (हिन्दी) बोहेम का विन-विन सर्पिल दृष्टिकोण: केवल 'सुरक्षा' को 'प्रयोज्यता' (प्राथमिकता) से ऊपर रखने के बजाय, बातचीत यह पता लगाती है कि प्रत्येक हितधारक जो चाहता है वह क्यों चाहता है और दोनों अंतर्निहित हितों को संतुष्ट करने वाले समाधान ढूंढता है - शायद बायोमेट्रिक प्रमाणीकरण सुरक्षा (मजबूत प्रमाणीकरण) और प्रयोज्य (याद रखने के लिए कोई पासवर्ड नहीं) दोनों को संतुष्ट करता है। यह रचनात्मक समस्या-समाधान शून्य-राशि प्राथमिकता से बेहतर परिणाम उत्पन्न करता है जहां एक पार्टी की जीत दूसरे की हार होती है।
2690
EN + हिं Easy
GB What is 'requirements smell' and what specific patterns indicate poorly written requirements?
IN 'आवश्यकताओं की गंध' क्या है और कौन से विशिष्ट पैटर्न खराब लिखित आवश्यकताओं को दर्शाते हैं?
A
Requirements smell refers to the physical odour of paper-based requirement documents in archives आवश्यकताओं की गंध अभिलेखागार में कागज-आधारित आवश्यकता दस्तावेजों की भौतिक गंध को संदर्भित करती है
B
Requirements smell (analogous to code smell) identifies surface patterns indicating underlying problems: vague adjectives ('user-friendly', 'fast'), conjunctions joining multiple requirements into one ('the system shall do X and Y'), passive voice obscuring responsibility, and unbounded superlatives ('all', 'every', 'never') आवश्यकताओं की गंध (कोड गंध के अनुरूप) अंतर्निहित समस्याओं को इंगित करने वाले सतह पैटर्न की पहचान करती है: अस्पष्ट विशेषण ('उपयोगकर्ता के अनुकूल', 'तेज'), कई आवश्यकताओं को एक में जोड़ने वाले संयोजन ('सिस्टम एक्स और वाई करेगा'), निष्क्रिय आवाज अस्पष्ट जिम्मेदारी, और असीमित अतिशयोक्ति ('सभी', 'प्रत्येक', 'कभी नहीं')
C
Requirements smell only applies to requirements written in languages other than English आवश्यकताएँ गंध केवल अंग्रेजी के अलावा अन्य भाषाओं में लिखी गई आवश्यकताओं पर लागू होती हैं
D
All requirements containing adjectives are automatically considered to have requirements smell विशेषणों से युक्त सभी आवश्यकताओं को स्वचालित रूप से आवश्यकताओं की गंध वाला माना जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) 'The system shall process orders quickly and notify the customer' has the conjunction smell — this is actually two requirements (processing speed and notification) bundled together, making it impossible to trace or test independently. 'All errors shall be logged' has the unbounded superlative smell — what about expected validation errors vs unexpected system errors? Each smell type signals a specific rewrite needed to make the requirement clear, testable, and traceable.
व्याख्या (हिन्दी) 'सिस्टम आदेशों को शीघ्रता से संसाधित करेगा और ग्राहक को सूचित करेगा' में संयोजन गंध है - यह वास्तव में दो आवश्यकताएं (प्रसंस्करण गति और अधिसूचना) एक साथ जुड़ी हुई हैं, जिससे स्वतंत्र रूप से पता लगाना या परीक्षण करना असंभव हो जाता है। 'सभी त्रुटियां लॉग की जाएंगी' में असीम उत्कृष्ट गंध है - अपेक्षित सत्यापन त्रुटियों बनाम अप्रत्याशित सिस्टम त्रुटियों के बारे में क्या? प्रत्येक गंध प्रकार आवश्यकता को स्पष्ट, परीक्षण योग्य और पता लगाने योग्य बनाने के लिए आवश्यक एक विशिष्ट पुनर्लेखन का संकेत देता है।
2691
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.
व्याख्या (हिन्दी) विशिष्ट आवश्यकताएं जोखिम संकेतक: क्रॉस-वैलिडेशन (उच्च संघर्ष जोखिम) के बिना एकल हितधारक द्वारा लिखी गई आवश्यकताएं, बिना किसी सिद्ध कार्यान्वयन (उच्च व्यवहार्यता जोखिम) के साथ उभरती हुई प्रौद्योगिकी का वर्णन करने वाली आवश्यकताएं, लंबित नियामक परिवर्तनों (उच्च अस्थिरता जोखिम) वाले डोमेन में आवश्यकताएं। इन्हें जल्दी पहचानने से लक्षित शमन की अनुमति मिलती है - व्यवहार्यता जोखिम के लिए प्रोटोटाइप, संघर्ष जोखिम के लिए बहु-हितधारक समीक्षा - बाद में उन्हें परियोजना में देरी के रूप में खोजने के बजाय।
2692
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.
व्याख्या (हिन्दी) तदर्थ संगठन असंगत रूप से आवश्यकताओं को पकड़ते हैं - कभी-कभी एक स्लैक संदेश, कभी-कभी एक ईमेल, कभी-कभी बिना किसी रिकॉर्ड के मौखिक समझौता। इससे ट्रैसेबिलिटी अंतराल और भूली हुई आवश्यकताएं पैदा होती हैं। व्यवस्थित संगठनों ने परिभाषित टेम्प्लेट (वोलेरे शेल), प्रशिक्षित एलिसिटेशन प्रैक्टिशनर, संरचित समीक्षा चौकियां, और टूलींग (जीरा, डोर्स) को द्विदिशीय ट्रैसेबिलिटी बनाए रखा है - जो कि विश्लेषक किस आवश्यकता को संभालता है, इसकी परवाह किए बिना लगातार गुणवत्ता को सक्षम करता है।
2693
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.
व्याख्या (हिन्दी) यह पुनरावृत्त/चतुर दृष्टिकोण के लिए मूलभूत तर्कों में से एक है: असंभव अग्रिम पूर्णता का पीछा करने के बजाय, वृद्धिशील रूप से वितरित करें और उपयोग को पहले से अज्ञात आवश्यकताओं को प्रकट करने दें। व्यावहारिक पूर्णता एक लागत-लाभ निर्णय है: सुरक्षित रूप से आगे बढ़ने के लिए पर्याप्त निर्दिष्ट करें, स्वीकार करें कि विकास के दौरान कुछ आवश्यकताएं सामने आएंगी, और उनकी खोज को परियोजना विफलता के रूप में मानने के बजाय उन्हें कुशलतापूर्वक शामिल करने के लिए तंत्र (परिवर्तन नियंत्रण, फीडबैक लूप) का निर्माण करें।
2694
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 से अधिक नहीं होगी' - यह मापने योग्य, परीक्षण योग्य सीमाएं स्थापित करते समय अंतर्निहित अनिश्चितता को स्वीकार करता है। नियतात्मक शुद्धता से सांख्यिकीय प्रदर्शन सीमा में बदलाव एमएल आवश्यकताओं इंजीनियरिंग के लिए मौलिक है।
2695
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 दिनों के भीतर सभी डेटा स्टोर से उपयोगकर्ता पीआईआई को स्थायी रूप से हटा देगा'), डिज़ाइन (कौन सी सेवाएं शामिल हैं), कोड (हटाने का कार्यान्वयन), साक्ष्य का परीक्षण करने के लिए (यह प्रमाणित करने के लिए कि विलोपन वास्तव में बैकअप और लॉग सहित सभी स्टोरों पर काम करता है) तक ट्रैसेबिलिटी की आवश्यकता है। इस श्रृंखला में कहीं भी अंतराल अनुपालन जोखिम और संभावित जुर्माने का प्रतिनिधित्व करता है।
2696
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 के बीच बदली गई हर आवश्यकता दिखाएं, और कौन से डिज़ाइन/परीक्षण कलाकृतियों की पुन: समीक्षा की आवश्यकता है')। उपभोक्ता ऐप बनाने वाले स्टार्टअप को औपचारिक ट्रैसेबिलिटी से अधिक जीरा की गति और डेवलपर-मित्रता की आवश्यकता होती है। कम-विनियमन संदर्भ के लिए एंटरप्राइज़ टूलींग का चयन करना अनावश्यक ओवरहेड जोड़ता है; विनियमित डोमेन के लिए हल्के टूलींग चुनने से अनुपालन जोखिम और ऑडिट विफलताएं पैदा होती हैं।
2697
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.
व्याख्या (हिन्दी) एक सत्यापन आवश्यकता पैटर्न व्यवस्थित रूप से लेखक को संकेत देता है: वैध सीमा क्या है? अमान्य इनपुट (अस्वीकार, डिफ़ॉल्ट, त्रुटि संदेश) पर क्या होता है? क्या प्रयास लॉग किया जाना चाहिए? क्या पुनः प्रयास की कोई अधिकतम संख्या है? इस आवश्यकता को शुरू से लिखने पर, एक विश्लेषक त्रुटि पथ को पूरी तरह से भूल सकता है - एक सामान्य अंतर जो केवल परीक्षण के दौरान खोजा गया है। पैटर्न प्रत्येक आवश्यकता श्रेणी के लिए 'पूर्ण' कैसा दिखता है, इसके बारे में संचित अनुभव को कूटबद्ध करता है।
2698
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 सेकंड के भीतर पूरा हो जाएगा') - प्रत्येक आवश्यकता को सीधे उसके व्यावसायिक तर्क से जोड़ता है।
2699
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.
व्याख्या (हिन्दी) प्रत्यक्ष कॉल में, सेवा ए को सेवा बी का पता पता होना चाहिए और जब ए कॉल करता है तो बी उपलब्ध होना चाहिए - तंग युग्मन। ईडीए में, सेवा ए किसी विषय पर 'ऑर्डरप्लेस्ड' प्रकाशित करती है, बिना यह जाने कि किसे परवाह है। सेवा बी (इन्वेंट्री), सी (शिपिंग), डी (एनालिटिक्स) प्रत्येक स्वतंत्र रूप से सदस्यता ले सकते हैं, ए को बदले बिना बाद में जोड़ा जा सकता है, और जब भी वे तैयार हों तब ईवेंट को संसाधित कर सकते हैं (भले ही वर्तमान में बंद हो, संदेश दृढ़ता के साथ)। यह अस्थायी और स्थानिक वियुग्मन ईडीए का मुख्य वास्तुशिल्प मूल्य है।
2700
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 रीड्स (ब्राउज़िंग) हो सकते हैं। सीक्यूआरएस के बिना, एक ही सामान्यीकृत स्कीमा दोनों को पूरा करती है - पढ़ने के लिए महंगे जोड़ों की आवश्यकता होती है, लिखना सरल होता है। सीक्यूआरएस एक अलग असामान्यीकृत रीड मॉडल बनाता है (यूआई की आवश्यकता वाले सटीक प्रश्नों के लिए अनुकूलित, राइट मॉडल से एसिंक्रोनस रूप से अपडेट किया गया) - रीड्स तेजी से कुंजी-मूल्य लुकअप बन जाते हैं जबकि राइट्स सामान्यीकृत कमांड मॉडल में लेनदेन संबंधी अखंडता बनाए रखते हैं।
2686–2700 of 2726