2416 Question 2416 EN + हिं Medium GB What is the 'Last Responsible Moment' principle in Lean Software Development and why is it valuable? IN लीन सॉफ्टवेयर डेवलपमेंट में 'लास्ट रिस्पॉन्सिबल मोमेंट' सिद्धांत क्या है और यह मूल्यवान क्यों है? A The latest moment to escalate a project risk to senior management वरिष्ठ प्रबंधन के लिए परियोजना जोखिम बढ़ाने का नवीनतम क्षण B Delaying irreversible decisions until maximum information is available, keeping options open — reducing the cost of wrong decisions made prematurely on insufficient information अधिकतम जानकारी उपलब्ध होने तक अपरिवर्तनीय निर्णयों में देरी करना, विकल्प खुले रखना - अपर्याप्त जानकारी पर समय से पहले लिए गए गलत निर्णयों की लागत को कम करना C The deadline after which project must be cancelled regardless of completion वह समय सीमा जिसके बाद परियोजना पूरी होने की परवाह किए बिना रद्द कर दी जानी चाहिए D The final sprint where all remaining backlog items must be completed अंतिम स्प्रिंट जहां सभी शेष बैकलॉग आइटम को पूरा किया जाना चाहिए ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) The Last Responsible Moment (Poppendieck) recognises that premature decisions made under uncertainty incur high error costs. By deliberately keeping options open and deciding only when the decision must be made, teams make better decisions with more data. व्याख्या (हिन्दी) द लास्ट रिस्पॉन्सिबल मोमेंट (पॉपेंडिएक) मानता है कि अनिश्चितता के तहत समय से पहले लिए गए निर्णयों में उच्च त्रुटि लागत होती है। जानबूझकर विकल्प खुले रखने और केवल तभी निर्णय लेने से जब निर्णय लिया जाना चाहिए, टीमें अधिक डेटा के साथ बेहतर निर्णय लेती हैं। 🎯 Exam Perspective Software Engineering के इस प्रश्न को — difficulty level "Medium" कई प्रतियोगी परीक्षाओं जैसे SSC CGL, IBPS, RRB और State-level परीक्षाओं में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions What is 'requirements creep' and what process practice... What is the 'requirements baseline' and what governance... What is 'prototyping' as a requirements elicitation tec... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2417 Question 2417 EN + हिं Easy GB What is the key distinction between functional and non-functional requirements, and which is typically harder to elicit? IN कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं के बीच मुख्य अंतर क्या है, और आमतौर पर किसका पता लगाना कठिन है? A Functional describe system performance; non-functional describe user stories कार्यात्मक प्रणाली के प्रदर्शन का वर्णन करें; गैर-कार्यात्मक उपयोगकर्ता कहानियों का वर्णन करें B Functional describe what the system does (behaviour); non-functional describe qualities like performance and security — non-functional are harder because stakeholders struggle to quantify them precisely कार्यात्मक वर्णन करता है कि सिस्टम क्या करता है (व्यवहार); गैर-कार्यात्मक प्रदर्शन और सुरक्षा जैसे गुणों का वर्णन करते हैं - गैर-कार्यात्मक कठिन हैं क्योंकि हितधारक उन्हें सटीक रूप से मापने के लिए संघर्ष करते हैं C Non-functional requirements are defined by developers; functional by customers गैर-कार्यात्मक आवश्यकताएं डेवलपर्स द्वारा परिभाषित की जाती हैं; ग्राहकों द्वारा कार्यात्मक D Functional only apply to UI layer; non-functional to backend कार्यात्मकता केवल यूआई परत पर लागू होती है; बैकएंड के लिए गैर-कार्यात्मक ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Functional requirements specify specific behaviours. Non-functional requirements (NFRs) specify quality attributes. NFRs are harder to elicit because stakeholders say 'it should be fast' rather than providing measurable thresholds, requiring analysts to probe for testable acceptance criteria. व्याख्या (हिन्दी) कार्यात्मक आवश्यकताएँ विशिष्ट व्यवहार निर्दिष्ट करती हैं। गैर-कार्यात्मक आवश्यकताएं (एनएफआर) गुणवत्ता विशेषताओं को निर्दिष्ट करती हैं। एनएफआर प्राप्त करना कठिन है क्योंकि हितधारकों का कहना है कि मापने योग्य सीमाएं प्रदान करने के बजाय 'यह तेज़ होना चाहिए', जिससे विश्लेषकों को परीक्षण योग्य स्वीकृति मानदंडों की जांच करने की आवश्यकता होती है। 🎯 Exam Perspective यह सवाल Software Engineering category का है — difficulty level "Easy", और UPSC, SSC, Banking और Police भर्ती के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What is 'requirements creep' and what process practice... What is 'requirements traceability' and why is it parti... What is the 'requirements baseline' and what governance... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2418 Question 2418 EN + हिं Easy GB What is 'requirements creep' and what process practice most effectively controls it? IN 'रिक्वायरमेंट्स क्रीप' क्या है और कौन सी प्रक्रिया अभ्यास इसे सबसे प्रभावी ढंग से नियंत्रित करती है? A Developers adding features without customer approval; controlled by daily standups डेवलपर्स ग्राहक की मंजूरी के बिना सुविधाएँ जोड़ रहे हैं; दैनिक स्टैंडअप द्वारा नियंत्रित B Uncontrolled addition of requirements after baseline without corresponding scope/budget/schedule adjustment; controlled through formal change control with impact analysis संबंधित दायरे/बजट/अनुसूची समायोजन के बिना बेसलाइन के बाद आवश्यकताओं का अनियंत्रित जोड़; प्रभाव विश्लेषण के साथ औपचारिक परिवर्तन नियंत्रण के माध्यम से नियंत्रित C Process of gradually making requirements more specific during elaboration विस्तार के दौरान आवश्यकताओं को धीरे-धीरे और अधिक विशिष्ट बनाने की प्रक्रिया D Inevitable and uncontrollable in any software project किसी भी सॉफ्टवेयर प्रोजेक्ट में अपरिहार्य और अनियंत्रित ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Requirements creep accumulates when stakeholders request changes informally after scope is agreed. Formal change control — requiring impact analysis on schedule, cost, and quality for every proposed change before approval — provides visibility and forces trade-off decisions. व्याख्या (हिन्दी) जब हितधारक दायरे पर सहमति के बाद अनौपचारिक रूप से परिवर्तन का अनुरोध करते हैं तो आवश्यकताएं कम हो जाती हैं। औपचारिक परिवर्तन नियंत्रण - अनुमोदन से पहले प्रत्येक प्रस्तावित परिवर्तन के लिए अनुसूची, लागत और गुणवत्ता पर प्रभाव विश्लेषण की आवश्यकता होती है - दृश्यता प्रदान करता है और व्यापार-बंद निर्णयों को मजबूर करता है। 🎯 Exam Perspective यह प्रश्न Software Engineering की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Easy"। इस तरह के प्रश्न अक्सर Railway, SSC, Banking और Defence परीक्षाओं जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What distinguishes 'elicitation' from 'analysis' in req... What is the 'Last Responsible Moment' principle in Lean... What does the Dependency Inversion Principle (DIP) stat... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2419 Question 2419 EN + हिं Medium GB What is the purpose of a 'use case' in requirements engineering and how does it differ from a user story? IN आवश्यकता इंजीनियरिंग में 'उपयोग मामले' का उद्देश्य क्या है और यह उपयोगकर्ता की कहानी से कैसे भिन्न है? A Use cases are UML diagrams; user stories are test cases by QA teams उपयोग के मामले यूएमएल आरेख हैं; उपयोगकर्ता कहानियाँ QA टीमों द्वारा परीक्षण मामले हैं B A use case is a detailed description of system/actor interaction achieving a goal including main/alternative flows; a user story is a lightweight conversational expression of a requirement that defers detail to conversation उपयोग का मामला मुख्य/वैकल्पिक प्रवाह सहित किसी लक्ष्य को प्राप्त करने वाले सिस्टम/अभिनेता इंटरैक्शन का विस्तृत विवरण है; एक उपयोगकर्ता कहानी एक आवश्यकता की हल्की-फुल्की संवादात्मक अभिव्यक्ति है जो बातचीत में विस्तार प्रदान करती है C Use cases only for OOP systems; user stories apply to all paradigms केवल OOP सिस्टम के लिए केस का उपयोग करें; उपयोगकर्ता कहानियाँ सभी प्रतिमानों पर लागू होती हैं D User stories completely replace use cases in modern software engineering उपयोगकर्ता कहानियाँ आधुनिक सॉफ़्टवेयर इंजीनियरिंग में उपयोग के मामलों को पूरी तरह से बदल देती हैं ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Use cases provide structured complete descriptions with success/failure scenarios, pre/postconditions, and alternative flows — suitable for complex interactions and contractual specifications. User stories are intentionally brief placeholders for conversations in agile teams. व्याख्या (हिन्दी) उपयोग के मामले सफलता/असफलता परिदृश्यों, पूर्व/उत्तर स्थितियों और वैकल्पिक प्रवाह के साथ संरचित पूर्ण विवरण प्रदान करते हैं - जटिल इंटरैक्शन और अनुबंध संबंधी विशिष्टताओं के लिए उपयुक्त। उपयोगकर्ता कहानियाँ सक्रिय टीमों में बातचीत के लिए जानबूझकर संक्षिप्त प्लेसहोल्डर हैं। 🎯 Exam Perspective Software Engineering से जुड़ा यह सवाल — difficulty level "Medium" उन students के लिए काम का है जो SSC, Railway, Banking और State PCS की तैयारी कर रहे हैं। बेहतर होगा कि explanation पढ़कर concept clear करें, ताकि exam में similar प्रश्न आने पर confusion न हो। 🔗 Related Questions What is the 'Law of Demeter' and what coupling problem... What is the 'Last Responsible Moment' principle in Lean... What is 'requirements creep' and what process practice... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2420 Question 2420 EN + हिं Medium GB What is the 'viewpoint-oriented' approach in requirements engineering and why is it valuable? IN आवश्यकता इंजीनियरिंग में 'दृष्टिकोण-उन्मुख' दृष्टिकोण क्या है और यह मूल्यवान क्यों है? A All requirements must be written from the end user's perspective only सभी आवश्यकताओं को केवल अंतिम उपयोगकर्ता के दृष्टिकोण से लिखा जाना चाहिए B It structures requirements elicitation around multiple distinct stakeholder perspectives, helping discover conflicts and requirements invisible from any single viewpoint यह कई अलग-अलग हितधारक दृष्टिकोणों के इर्द-गिर्द आवश्यकताओं की संरचना करता है, जिससे किसी एक दृष्टिकोण से अदृश्य संघर्षों और आवश्यकताओं को खोजने में मदद मिलती है C Only applicable to multi-tenant cloud systems केवल बहु-किरायेदार क्लाउड सिस्टम पर लागू D Requires each team member to write separate requirements documents independently प्रत्येक टीम सदस्य को स्वतंत्र रूप से अलग-अलग आवश्यकता दस्तावेज़ लिखने की आवश्यकता होती है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Different stakeholders (users, administrators, regulators) have different and sometimes conflicting views. Viewpoint-oriented methods systematically capture each perspective, then explicitly reconcile conflicts — better surfaced during elicitation than during testing. व्याख्या (हिन्दी) विभिन्न हितधारकों (उपयोगकर्ताओं, प्रशासकों, नियामकों) के अलग-अलग और कभी-कभी परस्पर विरोधी विचार होते हैं। दृष्टिकोण-उन्मुख तरीके प्रत्येक परिप्रेक्ष्य को व्यवस्थित रूप से पकड़ते हैं, फिर स्पष्ट रूप से संघर्षों को सुलझाते हैं - परीक्षण के दौरान की तुलना में स्पष्टीकरण के दौरान बेहतर ढंग से सामने आते हैं। 🎯 Exam Perspective SSC CGL, IBPS, RRB और State-level परीक्षाओं जैसी परीक्षाओं में Software Engineering से सवाल अक्सर पूछे जाते हैं — difficulty level "Medium"। इसलिए सिर्फ answer रटने के बजाय, नीचे दी गई explanation को ध्यान से पढ़ें और concept समझें। 🔗 Related Questions What is 'requirements creep' and what process practice... What is the purpose of a 'use case' in requirements eng... What is the 'gold plating' problem in requirements engi... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2421 Question 2421 EN + हिं Easy GB What is 'prototyping' as a requirements elicitation technique and what is its primary risk? IN आवश्यकताओं को पूरा करने की तकनीक के रूप में 'प्रोटोटाइपिंग' क्या है और इसका प्राथमिक जोखिम क्या है? A Creating a detailed architectural design before writing code; risk is over-specification कोड लिखने से पहले एक विस्तृत वास्तुशिल्प डिज़ाइन बनाना; जोखिम अति-विशिष्टता है B Building a partial/simulated version to elicit requirements through user interaction; primary risk is stakeholders mistaking the prototype for the final system and resisting necessary rework उपयोगकर्ता इंटरैक्शन के माध्यम से आवश्यकताओं को पूरा करने के लिए आंशिक/सिम्युलेटेड संस्करण का निर्माण; प्राथमिक जोखिम यह है कि हितधारक प्रोटोटाइप को अंतिम प्रणाली समझ लेते हैं और आवश्यक पुनर्कार्य का विरोध करते हैं C Always the cheapest requirements technique and should be used in all projects हमेशा सबसे सस्ती आवश्यकताओं वाली तकनीक और सभी परियोजनाओं में इसका उपयोग किया जाना चाहिए D Replaces requirements documentation entirely in modern development आधुनिक विकास में आवश्यकताओं के दस्तावेज़ीकरण को पूरी तरह से बदल देता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Prototyping is powerful for eliciting tacit requirements users can't articulate verbally. The critical risk (Sommerville's 'prototype as final system') is that stakeholders see working UI and assume the system is nearly done, pressuring the team to release the technically inadequate prototype. व्याख्या (हिन्दी) प्रोटोटाइप उन मौन आवश्यकताओं को प्राप्त करने के लिए शक्तिशाली है जिन्हें उपयोगकर्ता मौखिक रूप से व्यक्त नहीं कर सकते हैं। गंभीर जोखिम (सोमरविले का 'अंतिम सिस्टम के रूप में प्रोटोटाइप') यह है कि हितधारक काम कर रहे यूआई को देखते हैं और मान लेते हैं कि सिस्टम लगभग पूरा हो चुका है, जिससे टीम पर तकनीकी रूप से अपर्याप्त प्रोटोटाइप जारी करने का दबाव पड़ता है। 🎯 Exam Perspective अगर आप UPSC, SSC, Banking और Police भर्ती की तैयारी कर रहे हैं, तो Software Engineering का यह topic आपके लिए महत्वपूर्ण है — difficulty level "Easy"। Exam में accuracy बढ़ाने के लिए हर सवाल की explanation जरूर पढ़ें। 🔗 Related Questions What is the purpose of a 'use case' in requirements eng... What is the 'requirements baseline' and what governance... What distinguishes 'elicitation' from 'analysis' in req... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2422 Question 2422 EN + हिं Medium GB What distinguishes 'elicitation' from 'analysis' in requirements engineering? IN आवश्यकता इंजीनियरिंग में 'एलिसिटेशन' को 'विश्लेषण' से क्या अलग करता है? A Elicitation is done by customers; analysis by developers उद्दीपन ग्राहकों द्वारा किया जाता है; डेवलपर्स द्वारा विश्लेषण B Elicitation discovers and gathers requirements from stakeholders; analysis studies them for consistency, completeness, and resolves conflicts among elicited requirements एलीसिटेशन हितधारकों से आवश्यकताओं की खोज करता है और उन्हें एकत्र करता है; विश्लेषण निरंतरता, पूर्णता के लिए उनका अध्ययन करता है और उत्पन्न आवश्यकताओं के बीच टकराव का समाधान करता है C Elicitation only uses interviews; analysis only uses formal specification languages एलीसिटेशन केवल साक्षात्कार का उपयोग करता है; विश्लेषण केवल औपचारिक विनिर्देश भाषाओं का उपयोग करता है D Analysis precedes elicitation in the requirements process आवश्यकताओं की प्रक्रिया में विश्लेषण से पहले विश्लेषण किया जाता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Elicitation focuses on discovering what stakeholders need through interviews, workshops, observation. Analysis takes raw discovered requirements and studies them for internal consistency (no contradictions), completeness, and feasibility. Requirements from different stakeholders often conflict and analysis is where those conflicts are resolved. व्याख्या (हिन्दी) एलीसिटेशन साक्षात्कार, कार्यशालाओं, अवलोकन के माध्यम से यह पता लगाने पर केंद्रित है कि हितधारकों को क्या चाहिए। विश्लेषण कच्ची खोजी गई आवश्यकताओं को लेता है और आंतरिक स्थिरता (कोई विरोधाभास नहीं), पूर्णता और व्यवहार्यता के लिए उनका अध्ययन करता है। विभिन्न हितधारकों की आवश्यकताओं में अक्सर टकराव होता है और विश्लेषण वह जगह है जहां उन संघर्षों का समाधान किया जाता है। 🎯 Exam Perspective Software Engineering के इस प्रश्न को — difficulty level "Medium" कई प्रतियोगी परीक्षाओं जैसे Railway, SSC, Banking और Defence परीक्षाओं में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions What is 'requirements creep' and what process practice... In IEEE 830, what does the 'verifiability' property of... What does the Dependency Inversion Principle (DIP) stat... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2423 Question 2423 EN + हिं Easy GB In IEEE 830, what does the 'verifiability' property of a good requirement mean? IN आईईईई 830 में, एक अच्छी आवश्यकता की 'सत्यापनीयता' संपत्ति का क्या मतलब है? A Requirement has been verified by at least two senior stakeholders आवश्यकता को कम से कम दो वरिष्ठ हितधारकों द्वारा सत्यापित किया गया है B A cost-effective test, inspection, demonstration, or analysis method must exist that can confirm whether the requirement has been met एक लागत प्रभावी परीक्षण, निरीक्षण, प्रदर्शन या विश्लेषण विधि मौजूद होनी चाहिए जो पुष्टि कर सके कि आवश्यकता पूरी हो गई है या नहीं C Requirement source has been identified and documented आवश्यकता स्रोत की पहचान और दस्तावेजीकरण किया गया है D Requirement can be traced to a business objective in the project charter आवश्यकता का पता प्रोजेक्ट चार्टर में व्यावसायिक उद्देश्य से लगाया जा सकता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) IEEE 830 requires verifiability: a requirement must be stated so that a finite cost-effective procedure exists to check that the system satisfies it. 'User-friendly' is not verifiable; 'new users complete registration in under 3 minutes on first attempt' is verifiable through usability testing. व्याख्या (हिन्दी) आईईईई 830 को सत्यापन की आवश्यकता है: एक आवश्यकता बताई जानी चाहिए ताकि यह जांचने के लिए एक सीमित लागत प्रभावी प्रक्रिया मौजूद हो कि सिस्टम इसे पूरा करता है। 'उपयोगकर्ता-अनुकूल' सत्यापन योग्य नहीं है; 'नए उपयोगकर्ता पहले प्रयास में 3 मिनट से कम समय में पंजीकरण पूरा कर लेते हैं' को प्रयोज्यता परीक्षण के माध्यम से सत्यापित किया जा सकता है। 🎯 Exam Perspective यह सवाल Software Engineering category का है — difficulty level "Easy", और SSC, Railway, Banking और State PCS के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What does the Dependency Inversion Principle (DIP) stat... What is the 'Last Responsible Moment' principle in Lean... What is 'requirements creep' and what process practice... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2424 Question 2424 EN + हिं Easy GB What is the 'gold plating' problem in requirements engineering and from which side does it typically originate? IN आवश्यकताओं की इंजीनियरिंग में 'गोल्ड प्लेटिंग' समस्या क्या है और यह आमतौर पर किस तरफ से उत्पन्न होती है? A Customers demanding premium features outside budget ग्राहक बजट से बाहर प्रीमियम सुविधाओं की मांग कर रहे हैं B Developers adding unrequested features believing they improve the product — wasting effort on features customers may never use डेवलपर्स बिना अनुरोध वाली सुविधाएँ जोड़ रहे हैं, यह विश्वास करते हुए कि वे उत्पाद को बेहतर बनाते हैं - उन सुविधाओं पर प्रयास बर्बाद कर रहे हैं जिनका ग्राहक कभी उपयोग नहीं कर सकते हैं C Excessive requirements documentation adding cost without clarity अत्यधिक आवश्यकताओं वाला दस्तावेज़ स्पष्टता के बिना लागत जोड़ता है D A financial software engineering term for transaction security layers लेनदेन सुरक्षा परतों के लिए एक वित्तीय सॉफ्टवेयर इंजीनियरिंग शब्द ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Gold plating occurs when developers add features beyond what was requested, typically out of enthusiasm. While well-intentioned, it wastes resources, introduces unplanned testing requirements, and can complicate the interface. व्याख्या (हिन्दी) गोल्ड प्लेटिंग तब होती है जब डेवलपर्स आम तौर पर उत्साह से, अनुरोधित सुविधाओं से अधिक सुविधाएँ जोड़ते हैं। नेक इरादे से होते हुए भी, यह संसाधनों को बर्बाद करता है, अनियोजित परीक्षण आवश्यकताओं को प्रस्तुत करता है, और इंटरफ़ेस को जटिल बना सकता है। 🎯 Exam Perspective यह प्रश्न Software Engineering की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Easy"। इस तरह के प्रश्न अक्सर SSC CGL, IBPS, RRB और State-level परीक्षाओं जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What distinguishes a 'layered architecture' from a 'hex... What is 'prototyping' as a requirements elicitation tec... What is the key distinction between functional and non-... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2425 Question 2425 EN + हिं Medium GB What is 'requirements traceability' and why is it particularly important in safety-critical systems? IN 'आवश्यकताओं का पता लगाने की क्षमता' क्या है और यह सुरक्षा-महत्वपूर्ण प्रणालियों में विशेष रूप से महत्वपूर्ण क्यों है? A Ability to track who requested each requirement and their contact information यह ट्रैक करने की क्षमता कि प्रत्येक आवश्यकता और उनकी संपर्क जानकारी का अनुरोध किसने किया B Documented relationship linking requirements to design, code, and tests — enabling impact analysis and verification that all requirements are implemented; critical in safety systems for certification compliance डिज़ाइन, कोड और परीक्षणों से आवश्यकताओं को जोड़ने वाला दस्तावेज़ीकृत संबंध - प्रभाव विश्लेषण और सत्यापन को सक्षम करना कि सभी आवश्यकताएं लागू की गई हैं; प्रमाणीकरण अनुपालन के लिए सुरक्षा प्रणालियों में महत्वपूर्ण C Version control strategy for managing multiple branches of requirements documents आवश्यकता दस्तावेज़ों की अनेक शाखाओं के प्रबंधन के लिए संस्करण नियंत्रण रणनीति D Only applies to hardware requirements केवल हार्डवेयर आवश्यकताओं पर लागू होता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Traceability matrices link requirements to design decisions, implementation, and test cases bidirectionally. In safety-critical systems, regulators require proof every safety requirement has been implemented and tested — traceability is the evidence. व्याख्या (हिन्दी) ट्रैसेबिलिटी मैट्रिक्स आवश्यकताओं को डिजाइन निर्णयों, कार्यान्वयन और परीक्षण मामलों से द्विदिश रूप से जोड़ता है। सुरक्षा-महत्वपूर्ण प्रणालियों में, नियामकों को प्रमाण की आवश्यकता होती है कि प्रत्येक सुरक्षा आवश्यकता को लागू किया गया है और परीक्षण किया गया है - पता लगाने की क्षमता इसका प्रमाण है। 🎯 Exam Perspective Software Engineering से जुड़ा यह सवाल — difficulty level "Medium" उन students के लिए काम का है जो UPSC, SSC, Banking और Police भर्ती की तैयारी कर रहे हैं। बेहतर होगा कि explanation पढ़कर concept clear करें, ताकि exam में similar प्रश्न आने पर confusion न हो। 🔗 Related Questions What is the 'viewpoint-oriented' approach in requiremen... What is the purpose of a 'use case' in requirements eng... What is the 'Law of Demeter' and what coupling problem... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2426 Question 2426 EN + हिं Easy GB What is the 'requirements baseline' and what governance rules typically apply to it? IN 'आवश्यकताओं की आधार रेखा' क्या है और इस पर आमतौर पर कौन से शासन नियम लागू होते हैं? A A preliminary draft of requirements used only for initial cost estimation आवश्यकताओं का प्रारंभिक मसौदा केवल प्रारंभिक लागत अनुमान के लिए उपयोग किया जाता है B A formally approved version of the requirements document serving as the agreed reference; changes require formal change control — impact assessment, CCB approval, and version management सहमत संदर्भ के रूप में कार्य करने वाले आवश्यकता दस्तावेज़ का औपचारिक रूप से अनुमोदित संस्करण; परिवर्तनों के लिए औपचारिक परिवर्तन नियंत्रण की आवश्यकता होती है - प्रभाव मूल्यांकन, सीसीबी अनुमोदन और संस्करण प्रबंधन C Automatically updated whenever a developer commits code जब भी कोई डेवलपर कोड करता है तो स्वचालित रूप से अपडेट हो जाता है D Produced by the testing team after system testing is complete सिस्टम परीक्षण पूरा होने के बाद परीक्षण टीम द्वारा उत्पादित किया जाता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) A requirements baseline establishes a controlled reference. Once baselined, requirements are under configuration management — changes cannot be made informally. A Change Control Board evaluates impact on cost, schedule, and quality, approving or rejecting proposed changes. व्याख्या (हिन्दी) आवश्यकताओं की आधार रेखा एक नियंत्रित संदर्भ स्थापित करती है। एक बार आधारभूत हो जाने पर, आवश्यकताएँ कॉन्फ़िगरेशन प्रबंधन के अंतर्गत होती हैं - परिवर्तन अनौपचारिक रूप से नहीं किए जा सकते। एक परिवर्तन नियंत्रण बोर्ड प्रस्तावित परिवर्तनों को स्वीकृत या अस्वीकार करते हुए लागत, अनुसूची और गुणवत्ता पर प्रभाव का मूल्यांकन करता है। 🎯 Exam Perspective Railway, SSC, Banking और Defence परीक्षाओं जैसी परीक्षाओं में Software Engineering से सवाल अक्सर पूछे जाते हैं — difficulty level "Easy"। इसलिए सिर्फ answer रटने के बजाय, नीचे दी गई explanation को ध्यान से पढ़ें और concept समझें। 🔗 Related Questions What is the difference between 'cohesion' and 'coupling... In IEEE 830, what does the 'verifiability' property of... What is 'prototyping' as a requirements elicitation tec... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2427 Question 2427 EN + हिं Hard GB What is the difference between 'cohesion' and 'coupling' in software design and what is the ideal goal? IN सॉफ़्टवेयर डिज़ाइन में 'सामंजस्य' और 'युग्मन' के बीच क्या अंतर है और आदर्श लक्ष्य क्या है? A High coupling and low cohesion is ideal; it allows maximum code reuse उच्च युग्मन और निम्न सामंजस्य आदर्श है; यह अधिकतम कोड पुन: उपयोग की अनुमति देता है B Cohesion is how strongly related responsibilities within a module are; coupling is how dependent modules are on each other — ideal is high cohesion and low coupling सामंजस्य यह है कि एक मॉड्यूल के भीतर जिम्मेदारियाँ कितनी मजबूती से संबंधित हैं; युग्मन यह है कि मॉड्यूल एक दूसरे पर कैसे निर्भर होते हैं - आदर्श उच्च सामंजस्य और कम युग्मन है C Cohesion refers to number of methods in a class; coupling to number of classes in a package सामंजस्य एक वर्ग में विधियों की संख्या को संदर्भित करता है; एक पैकेज में कक्षाओं की संख्या को युग्मित करना D Both cohesion and coupling should be minimised सामंजस्य और युग्मन दोनों को कम से कम किया जाना चाहिए ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) High cohesion means a module has a single well-defined purpose (SRP). Low coupling means modules interact through minimal interfaces without knowing each other's internals. Together they enable independent modification, testing, and replacement of modules. व्याख्या (हिन्दी) उच्च सामंजस्य का मतलब है कि एक मॉड्यूल का एक ही अच्छी तरह से परिभाषित उद्देश्य (एसआरपी) है। कम युग्मन का मतलब है कि मॉड्यूल एक-दूसरे के आंतरिक पहलुओं को जाने बिना न्यूनतम इंटरफेस के माध्यम से बातचीत करते हैं। साथ में वे मॉड्यूल के स्वतंत्र संशोधन, परीक्षण और प्रतिस्थापन को सक्षम करते हैं। 🎯 Exam Perspective अगर आप SSC, Railway, Banking और State PCS की तैयारी कर रहे हैं, तो Software Engineering का यह topic आपके लिए महत्वपूर्ण है — difficulty level "Hard"। Exam में accuracy बढ़ाने के लिए हर सवाल की explanation जरूर पढ़ें। 🔗 Related Questions What distinguishes 'elicitation' from 'analysis' in req... In IEEE 830, what does the 'verifiability' property of... What is the 'Law of Demeter' and what coupling problem... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2428 Question 2428 EN + हिं Easy GB What does the Dependency Inversion Principle (DIP) state and what design problem does it solve? IN निर्भरता व्युत्क्रम सिद्धांत (डीआईपी) क्या बताता है और यह किस डिज़ाइन समस्या का समाधान करता है? A All class dependencies should be injected through constructors rather than setters सभी वर्ग निर्भरताओं को सेटर्स के बजाय कंस्ट्रक्टर्स के माध्यम से इंजेक्ट किया जाना चाहिए B High-level modules should not depend on low-level modules; both should depend on abstractions — solving the problem where changing a low-level component forces changes throughout the system उच्च-स्तरीय मॉड्यूल को निम्न-स्तरीय मॉड्यूल पर निर्भर नहीं होना चाहिए; दोनों को अमूर्तता पर निर्भर होना चाहिए - उस समस्या को हल करना जहां निम्न-स्तरीय घटक को बदलने से पूरे सिस्टम में परिवर्तन होता है C All software dependencies must be managed by a centralised dependency registry सभी सॉफ़्टवेयर निर्भरताएँ एक केंद्रीकृत निर्भरता रजिस्ट्री द्वारा प्रबंधित की जानी चाहिए D Inheritance is prohibited; composition required instead विरासत निषिद्ध है; इसके बजाय रचना की आवश्यकता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) DIP inverts the traditional dependency flow. Business logic depending on a database interface (abstraction) rather than the database directly means changing the database doesn't break business logic. This decouples layers and makes components independently replaceable. व्याख्या (हिन्दी) डीआईपी पारंपरिक निर्भरता प्रवाह को उलट देता है। व्यावसायिक तर्क डेटाबेस के बजाय डेटाबेस इंटरफ़ेस (अमूर्त) पर निर्भर करता है, इसका सीधा मतलब है कि डेटाबेस को बदलने से व्यावसायिक तर्क नहीं टूटता है। यह परतों को अलग करता है और घटकों को स्वतंत्र रूप से बदलने योग्य बनाता है। 🎯 Exam Perspective Software Engineering के इस प्रश्न को — difficulty level "Easy" कई प्रतियोगी परीक्षाओं जैसे SSC CGL, IBPS, RRB और State-level परीक्षाओं में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions What is the 'gold plating' problem in requirements engi... What distinguishes a 'layered architecture' from a 'hex... What is 'requirements creep' and what process practice... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2429 Question 2429 EN + हिं Easy GB What is the 'Law of Demeter' and what coupling problem does it address? IN 'डेमेटर का नियम' क्या है और यह किस युग्मन समस्या का समाधान करता है? A Each class must have at most ten methods प्रत्येक कक्षा में अधिकतम दस विधियाँ होनी चाहिए B A method should only call methods of its own class, its parameters, objects it creates, or direct components — preventing 'train wreck' chaining that creates hidden long-range coupling एक विधि को केवल अपने स्वयं के वर्ग, उसके मापदंडों, उसके द्वारा बनाई गई वस्तुओं, या प्रत्यक्ष घटकों के तरीकों को कॉल करना चाहिए - 'ट्रेन मलबे' श्रृंखला को रोकना जो छिपी हुई लंबी दूरी की युग्मन बनाता है C Global variables are prohibited in object-oriented programs ऑब्जेक्ट-ओरिएंटेड प्रोग्राम में वैश्विक चर निषिद्ध हैं D All class attributes must be private with public getters and setters सभी वर्ग विशेषताएँ सार्वजनिक गेटर्स और सेटर्स के साथ निजी होनी चाहिए ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Train wreck code like customer.getWallet().getCurrency().getSymbol() makes the caller dependent on the entire object graph's internal structure. The Law of Demeter limits coupling by requiring objects to communicate only with immediate neighbours, enforcing encapsulation. व्याख्या (हिन्दी) ट्रेन व्रेक कोड जैसे customer.getWallet().getCurrency().getSymbol() कॉलर को संपूर्ण ऑब्जेक्ट ग्राफ़ की आंतरिक संरचना पर निर्भर बनाता है। डेमेटर का नियम वस्तुओं को केवल निकटतम पड़ोसियों के साथ संचार करने की आवश्यकता के द्वारा युग्मन को सीमित करता है, जिससे एनकैप्सुलेशन लागू होता है। 🎯 Exam Perspective यह सवाल Software Engineering category का है — difficulty level "Easy", और UPSC, SSC, Banking और Police भर्ती के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What does the Dependency Inversion Principle (DIP) stat... What is the 'viewpoint-oriented' approach in requiremen... What is the difference between 'cohesion' and 'coupling... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
2430 Question 2430 EN + हिं Medium GB What distinguishes a 'layered architecture' from a 'hexagonal (ports and adapters) architecture'? IN 'स्तरित आर्किटेक्चर' को 'हेक्सागोनल (पोर्ट और एडाप्टर) आर्किटेक्चर' से क्या अलग करता है? A Layered is for web applications; hexagonal is for desktop applications लेयर्ड वेब अनुप्रयोगों के लिए है; हेक्सागोनल डेस्कटॉप अनुप्रयोगों के लिए है B Layered enforces directional dependency flow (UI→Business→Data); hexagonal puts business logic at the centre with all external concerns as interchangeable adapters connecting through ports स्तरित दिशात्मक निर्भरता प्रवाह को लागू करता है (यूआई→व्यवसाय→डेटा); हेक्सागोनल बंदरगाहों के माध्यम से जुड़ने वाले विनिमेय एडेप्टर के रूप में सभी बाहरी चिंताओं के साथ व्यावसायिक तर्क को केंद्र में रखता है C Hexagonal has exactly six layers; layered can have any number हेक्सागोनल में ठीक छह परतें होती हैं; स्तरित में कोई भी संख्या हो सकती है D Both are identical; hexagonal is a newer name for layered दोनों एक जैसे हैं; हेक्सागोनल लेयर्ड का नया नाम है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) In layered architecture, business logic depends on the database — making database changes ripple upward. Alistair Cockburn's Hexagonal architecture isolates the domain model at the core; all I/O are adapters the domain doesn't depend on, enabling full testability without infrastructure. व्याख्या (हिन्दी) स्तरित वास्तुकला में, व्यावसायिक तर्क डेटाबेस पर निर्भर करता है - जिससे डेटाबेस परिवर्तन ऊपर की ओर बढ़ते हैं। एलिस्टेयर कॉकबर्न की हेक्सागोनल वास्तुकला डोमेन मॉडल को मूल रूप से अलग करती है; सभी I/O एडेप्टर हैं जिन पर डोमेन निर्भर नहीं है, जो बुनियादी ढांचे के बिना पूर्ण परीक्षण योग्यता को सक्षम करते हैं। 🎯 Exam Perspective यह प्रश्न Software Engineering की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Medium"। इस तरह के प्रश्न अक्सर Railway, SSC, Banking और Defence परीक्षाओं जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What is the difference between 'cohesion' and 'coupling... What is the 'Law of Demeter' and what coupling problem... What is 'requirements creep' and what process practice... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)