Software Engineering — MCQ Practice

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

📚 647 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
647 questions
481
EN + हिं Easy
GB What is the 'three amigos' practice in agile and what communication failure does it prevent?
IN एजाइल में 'थ्री एमिगोस' अभ्यास क्या है और यह किस संचार विफलता को रोकता है?
A
Three amigos refers to the three mandatory Scrum ceremonies: planning, daily standup, and retrospective तीन अमीगोस तीन अनिवार्य स्क्रम समारोहों को संदर्भित करते हैं: योजना, दैनिक स्टैंडअप और पूर्वव्यापी
B
Three amigos brings together a business analyst/product owner, developer, and tester to collaboratively refine a user story before implementation — preventing the costly failure of developers building something different from what the BA specified and different from what the tester expected to verify कार्यान्वयन से पहले एक उपयोगकर्ता कहानी को सहयोगात्मक रूप से परिष्कृत करने के लिए तीन अमीगो एक व्यवसाय विश्लेषक/उत्पाद स्वामी, डेवलपर और परीक्षक को एक साथ लाते हैं - बीए द्वारा निर्दिष्ट और परीक्षक द्वारा सत्यापित करने की अपेक्षा से अलग कुछ बनाने में डेवलपर्स की महंगी विफलता को रोकते हैं।
C
Three amigos is a retrospective technique where three senior team members vote on process improvements थ्री एमिगोस एक पूर्वव्यापी तकनीक है जहां टीम के तीन वरिष्ठ सदस्य प्रक्रिया में सुधार पर मतदान करते हैं
D
The term 'three amigos' only applies to SAFe and has no meaning in Scrum or Kanban 'थ्री एमिगोज़' शब्द केवल SAFe पर लागू होता है और स्क्रम या कानबन में इसका कोई अर्थ नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The classic agile failure: BA writes a story, developer builds their interpretation, tester writes tests based on their interpretation — three different understandings diverge silently until integration. Three amigos (Specification by Example, Gojko Adzic) has all three roles author concrete examples together before a sprint, creating shared understanding and concrete acceptance criteria that all three parties agree represent the same requirement.
व्याख्या (हिन्दी) क्लासिक चुस्त विफलता: बीए एक कहानी लिखता है, डेवलपर अपनी व्याख्या बनाता है, परीक्षक उनकी व्याख्या के आधार पर परीक्षण लिखते हैं - तीन अलग-अलग समझ एकीकरण तक चुपचाप अलग हो जाती हैं। तीन अमीगोस (उदाहरण द्वारा विशिष्टता, गोज्को एडज़िक) में स्प्रिंट से पहले सभी तीन भूमिकाएं लेखक के ठोस उदाहरण हैं, जो साझा समझ और ठोस स्वीकृति मानदंड बनाते हैं, जिससे सभी तीन पक्ष सहमत होते हैं और एक ही आवश्यकता का प्रतिनिधित्व करते हैं।
482
EN + हिं Easy
GB What is 'behaviour-driven development' (BDD) and what problem with TDD does it address?
IN 'व्यवहार-संचालित विकास' (बीडीडी) क्या है और यह टीडीडी से जुड़ी किस समस्या का समाधान करता है?
A
BDD is a testing framework that automatically generates test cases from user interface screenshots बीडीडी एक परीक्षण ढांचा है जो उपयोगकर्ता इंटरफ़ेस स्क्रीनशॉट से स्वचालित रूप से परीक्षण मामले उत्पन्न करता है
B
BDD reformulates TDD around system behaviour described in business language (Given-When-Then) — addressing TDD's problem that developer-named unit tests (testAddUser, testSaveRecord) don't communicate intent to business stakeholders or serve as living documentation बीडीडी व्यावसायिक भाषा में वर्णित सिस्टम व्यवहार के आसपास टीडीडी का सुधार करता है (दिया-जब-तब) - टीडीडी की समस्या का समाधान करते हुए कि डेवलपर-नामित इकाई परीक्षण (testAddUser, testSaveRecord) व्यावसायिक हितधारकों के इरादे को संप्रेषित नहीं करते हैं या जीवित दस्तावेज़ के रूप में काम नहीं करते हैं
C
BDD is identical to TDD but uses a different assertion library (Jasmine vs JUnit) बीडीडी टीडीडी के समान है लेकिन एक अलग अभिकथन लाइब्रेरी का उपयोग करता है (जैस्मीन बनाम जुनीट)
D
BDD was developed as a replacement for unit testing in Python projects only बीडीडी को केवल पायथन परियोजनाओं में यूनिट परीक्षण के प्रतिस्थापन के रूप में विकसित किया गया था
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Dan North coined BDD (2003) after observing that developers struggled to know what to test and tests often didn't reflect intent. BDD scenarios (Given [context], When [action], Then [outcome]) are: readable by non-developers, serve as living documentation, directly trace to business requirements, and when automated (Cucumber, Behave) provide executable specifications.
व्याख्या (हिन्दी) डैन नॉर्थ ने यह देखने के बाद बीडीडी (2003) बनाया कि डेवलपर्स को यह जानने के लिए संघर्ष करना पड़ता है कि क्या परीक्षण करना है और परीक्षण अक्सर इरादे को प्रतिबिंबित नहीं करते हैं। बीडीडी परिदृश्य (दी गई [संदर्भ], जब [क्रिया], तब [परिणाम]) हैं: गैर-डेवलपर्स द्वारा पढ़ने योग्य, जीवित दस्तावेज़ के रूप में कार्य करते हैं, सीधे व्यावसायिक आवश्यकताओं का पता लगाते हैं, और जब स्वचालित होते हैं (ककड़ी, व्यवहार) निष्पादन योग्य विनिर्देश प्रदान करते हैं।
483
EN + हिं Easy
GB What is 'technical spike' in agile development and when should it be used?
IN त्वरित विकास में 'तकनीकी स्पाइक' क्या है और इसका उपयोग कब किया जाना चाहिए?
A
A technical spike is an emergency debugging session for production incidents तकनीकी स्पाइक उत्पादन घटनाओं के लिए एक आपातकालीन डिबगिंग सत्र है
B
A technical spike is a time-boxed research or proof-of-concept effort used when a team faces significant technical uncertainty — the spike produces knowledge (not shippable product) that enables accurate estimation and informed design decisions तकनीकी स्पाइक एक समय-आधारित अनुसंधान या प्रूफ-ऑफ-कॉन्सेप्ट प्रयास है जिसका उपयोग तब किया जाता है जब एक टीम को महत्वपूर्ण तकनीकी अनिश्चितता का सामना करना पड़ता है - स्पाइक ज्ञान उत्पन्न करता है (शिप करने योग्य उत्पाद नहीं) जो सटीक अनुमान और सूचित डिजाइन निर्णयों को सक्षम बनाता है।
C
Technical spikes are only used when team members disagree about technology choices तकनीकी स्पाइक्स का उपयोग केवल तभी किया जाता है जब टीम के सदस्य प्रौद्योगिकी विकल्पों के बारे में असहमत हों
D
A technical spike is a sprint dedicated entirely to bug fixing and technical debt reduction तकनीकी स्पाइक एक स्प्रिंट है जो पूरी तरह से बग फिक्सिंग और तकनीकी ऋण कटौती के लिए समर्पित है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) When a story has uncertain technical feasibility (e.g., 'can our system integrate with vendor X's new API?'), estimating it is impossible without investigation. A spike — say, 2 days timebox — produces a working prototype answering the key question. The spike itself is never shipped; it produces knowledge that informs the actual story implementation estimate and design approach.
व्याख्या (हिन्दी) जब किसी कहानी में अनिश्चित तकनीकी व्यवहार्यता होती है (उदाहरण के लिए, 'क्या हमारा सिस्टम विक्रेता एक्स के नए एपीआई के साथ एकीकृत हो सकता है?'), तो जांच के बिना इसका अनुमान लगाना असंभव है। एक स्पाइक - मान लीजिए, 2 दिन का टाइमबॉक्स - मुख्य प्रश्न का उत्तर देने वाला एक कार्यशील प्रोटोटाइप तैयार करता है। स्पाइक स्वयं कभी भी शिप नहीं किया जाता है; यह ज्ञान पैदा करता है जो वास्तविक कहानी कार्यान्वयन अनुमान और डिजाइन दृष्टिकोण को सूचित करता है।
484
EN + हिं Easy
GB What is 'story mapping' in agile and what planning problem does it solve that a flat backlog creates?
IN एजाइल में 'स्टोरी मैपिंग' क्या है और यह किस योजना समस्या का समाधान करता है जो एक फ्लैट बैकलॉग बनाता है?
A
Story mapping is a technique for estimating story point values through collaborative card sorting स्टोरी मैपिंग सहयोगी कार्ड सॉर्टिंग के माध्यम से कहानी बिंदु मूल्यों का अनुमान लगाने की एक तकनीक है
B
Story mapping arranges stories in a two-dimensional grid (horizontal: user journey steps; vertical: priority/detail) — solving the flat backlog's problem of losing the narrative and context of how features relate to user goals स्टोरी मैपिंग कहानियों को दो-आयामी ग्रिड (क्षैतिज: उपयोगकर्ता यात्रा चरण; लंबवत: प्राथमिकता/विस्तार) में व्यवस्थित करती है - कथा और संदर्भ को खोने की फ्लैट बैकलॉग की समस्या को हल करना कि विशेषताएं उपयोगकर्ता के लक्ष्यों से कैसे संबंधित हैं
C
Story mapping is only used during retrospectives to categorise completed stories पूरी कहानियों को वर्गीकृत करने के लिए स्टोरी मैपिंग का उपयोग केवल पूर्वव्यापी के दौरान किया जाता है
D
Story mapping replaces the Product Backlog entirely in SAFe framework स्टोरी मैपिंग पूरी तरह से SAFe फ्रेमवर्क में उत्पाद बैकलॉग को प्रतिस्थापित कर देती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Jeff Patton's User Story Mapping addresses a common agile failure: a flat prioritised backlog loses the 'why' and 'how users flow through the system'. The map's backbone (top row) shows the user journey; rows below slice the backbone into deliverable increments. This reveals which slices deliver a walking skeleton vs. which add depth — enabling release planning that delivers coherent user value rather than disconnected feature fragments.
व्याख्या (हिन्दी) जेफ़ पैटन की उपयोगकर्ता स्टोरी मैपिंग एक सामान्य त्वरित विफलता को संबोधित करती है: एक फ्लैट प्राथमिकता वाला बैकलॉग 'क्यों' और 'उपयोगकर्ता सिस्टम के माध्यम से कैसे प्रवाहित होते हैं' को खो देता है। मानचित्र की रीढ़ (शीर्ष पंक्ति) उपयोगकर्ता की यात्रा दिखाती है; नीचे दी गई पंक्तियाँ रीढ़ की हड्डी को वितरण योग्य वेतन वृद्धि में काटती हैं। इससे पता चलता है कि कौन से स्लाइस एक चलने वाला कंकाल प्रदान करते हैं बनाम जो गहराई जोड़ते हैं - रिलीज योजना को सक्षम करते हैं जो डिस्कनेक्ट किए गए फीचर टुकड़ों के बजाय सुसंगत उपयोगकर्ता मूल्य प्रदान करता है।
485
EN + हिं Medium
GB What is the 'Cynefin framework' and how does it inform process model selection in software projects?
IN 'साइनफिन फ्रेमवर्क' क्या है और यह सॉफ्टवेयर परियोजनाओं में प्रक्रिया मॉडल चयन को कैसे सूचित करता है?
A
Cynefin is a risk management tool developed by Boehm for the Spiral model सिनेफ़िन स्पाइरल मॉडल के लिए बोहेम द्वारा विकसित एक जोखिम प्रबंधन उपकरण है
B
Cynefin (Snowden) categorises problems as Obvious, Complicated, Complex, or Chaotic — guiding process selection: Waterfall suits Obvious/Complicated domains (best practices exist); Agile suits Complex domains (practices emerge through experimentation); chaotic domains require immediate action सिनेफिन (स्नोडेन) समस्याओं को स्पष्ट, जटिल, जटिल या अराजक के रूप में वर्गीकृत करता है - मार्गदर्शक प्रक्रिया चयन: झरना स्पष्ट/जटिल डोमेन के लिए उपयुक्त है (सर्वोत्तम अभ्यास मौजूद हैं); एजाइल जटिल डोमेन के लिए उपयुक्त है (प्रयोग प्रयोग के माध्यम से उभरते हैं); अराजक डोमेन पर तत्काल कार्रवाई की आवश्यकता है
C
Cynefin framework mandates that all software projects must use Agile regardless of domain type सिनेफिन फ्रेमवर्क का आदेश है कि सभी सॉफ्टवेयर प्रोजेक्टों को डोमेन प्रकार की परवाह किए बिना एजाइल का उपयोग करना चाहिए
D
Cynefin is a database design framework unrelated to software process models सिनेफ़िन एक डेटाबेस डिज़ाइन फ़्रेमवर्क है जो सॉफ़्टवेयर प्रक्रिया मॉडल से असंबंधित है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Cynefin provides a theoretical basis for process model selection. Complicated problems (aircraft navigation algorithms) have knowable solutions requiring expert analysis — plan-driven works. Complex problems (social network features, ML products) have emergent solutions knowable only through experimentation — agile works. Applying Waterfall to complex domains creates expensive failures; applying Agile to complicated safety-critical systems creates dangerous ones.
व्याख्या (हिन्दी) सिनेफ़िन प्रक्रिया मॉडल चयन के लिए एक सैद्धांतिक आधार प्रदान करता है। जटिल समस्याओं (विमान नेविगेशन एल्गोरिदम) में जानने योग्य समाधान होते हैं जिनके लिए विशेषज्ञ विश्लेषण की आवश्यकता होती है - योजना-संचालित कार्य। जटिल समस्याओं (सोशल नेटवर्क सुविधाएँ, एमएल उत्पाद) के उभरते समाधान केवल प्रयोग - चुस्त कार्यों के माध्यम से ही जाने जा सकते हैं। जटिल डोमेन पर वॉटरफ़ॉल लागू करने से महंगी विफलताएँ उत्पन्न होती हैं; जटिल सुरक्षा-महत्वपूर्ण प्रणालियों में एजाइल को लागू करने से खतरनाक प्रणालियाँ बनती हैं।
486
EN + हिं Easy
GB What is the 'requirements prioritisation' technique MoSCoW and what critical risk does ignoring it introduce?
IN 'आवश्यकताओं को प्राथमिकता देने' की तकनीक MoSCoW क्या है और इसे अनदेखा करने से कौन सा गंभीर जोखिम उत्पन्न होता है?
A
MoSCoW is a database query language for requirements management tools MoSCoW आवश्यकता प्रबंधन टूल के लिए एक डेटाबेस क्वेरी भाषा है
B
MoSCoW classifies requirements as Must-have, Should-have, Could-have, and Won't-have this time; ignoring it risks delivering complete features of low importance while must-have requirements remain unfinished at delivery MoSCoW इस बार आवश्यकताओं को अवश्य होना चाहिए, होना चाहिए, हो सकता है और नहीं होगा के रूप में वर्गीकृत करता है; इसे अनदेखा करने से कम महत्व की संपूर्ण सुविधाएँ प्रदान करने का जोखिम होता है जबकि डिलीवरी के समय आवश्यक आवश्यकताएँ अधूरी रह जाती हैं
C
MoSCoW is only applicable to government procurement projects with regulatory requirements MoSCoW केवल नियामक आवश्यकताओं वाली सरकारी खरीद परियोजनाओं पर लागू है
D
MoSCoW eliminates the need for requirements elicitation by using stakeholder votes MoSCoW हितधारक वोटों का उपयोग करके आवश्यकताओं को प्राप्त करने की आवश्यकता को समाप्त करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) MoSCoW (Dai Clegg, DSDM) is critical for timeboxed delivery. Without prioritisation, teams treat all requirements equally and risk spending 80% of effort on 20% of the value. Must-haves define the product's minimum viable set; everything else can drop if time runs out. Projects that don't use MoSCoW often deliver everything but the essential features last — meeting contractual scope but failing operationally.
व्याख्या (हिन्दी) MoSCoW (दाई क्लेग, DSDM) समयबद्ध डिलीवरी के लिए महत्वपूर्ण है। प्राथमिकता के बिना, टीमें सभी आवश्यकताओं को समान रूप से मानती हैं और मूल्य के 20% पर 80% प्रयास खर्च करने का जोखिम उठाती हैं। उत्पाद के न्यूनतम व्यवहार्य सेट को परिभाषित करना आवश्यक है; यदि समय समाप्त हो गया तो बाकी सब कुछ गिर सकता है। जो परियोजनाएँ MoSCoW का उपयोग नहीं करती हैं वे अक्सर आवश्यक सुविधाओं को छोड़कर सब कुछ प्रदान करती हैं - संविदात्मक दायरे को पूरा करना लेकिन परिचालन में विफल होना।
487
EN + हिं Easy
GB What is the 'Volere requirements shell' and what categories of information does it capture for each requirement?
IN 'वोलेरे रिक्वायरमेंट शेल' क्या है और यह प्रत्येक आवश्यकता के लिए किस श्रेणी की जानकारी प्राप्त करता है?
A
Volere shell is a UML diagram template for drawing use case diagrams वोलेरे शेल उपयोग केस आरेख बनाने के लिए एक यूएमएल आरेख टेम्पलेट है
B
Volere shell is a template for documenting individual requirements capturing: requirement number, description, rationale, originator, fit criterion, customer satisfaction/dissatisfaction, conflicts, priority, history, and supporting material वोलेरे शेल व्यक्तिगत आवश्यकताओं को दर्ज करने के लिए एक टेम्पलेट है: आवश्यकता संख्या, विवरण, तर्क, प्रवर्तक, फिट मानदंड, ग्राहक संतुष्टि/असंतोष, संघर्ष, प्राथमिकता, इतिहास और सहायक सामग्री।
C
Volere shell is a UX design pattern for capturing user interface requirements वोलेरे शेल यूजर इंटरफ़ेस आवश्यकताओं को कैप्चर करने के लिए एक यूएक्स डिज़ाइन पैटर्न है
D
Volere shell is an automated requirements extraction tool for legacy codebases वोलेरे शेल लीगेसी कोडबेस के लिए एक स्वचालित आवश्यकता निष्कर्षण उपकरण है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Robertson and Robertson's Volere Requirements Shell provides a systematic checklist ensuring every requirement is fully specified: fit criterion (verifiable measure of satisfaction), customer satisfaction/dissatisfaction ratings (motivating the requirement's importance), originator, conflicts, and history. It prevents thin requirements that say what without saying why or how to verify.
व्याख्या (हिन्दी) रॉबर्टसन और रॉबर्टसन की वोलेरे रिक्वायरमेंट्स शेल एक व्यवस्थित चेकलिस्ट प्रदान करती है जो यह सुनिश्चित करती है कि प्रत्येक आवश्यकता पूरी तरह से निर्दिष्ट है: फिट मानदंड (संतुष्टि का सत्यापन योग्य उपाय), ग्राहक संतुष्टि/असंतोष रेटिंग (आवश्यकता के महत्व को प्रेरित करना), प्रवर्तक, संघर्ष और इतिहास। यह उन पतली आवश्यकताओं को रोकता है जो यह बताए बिना कि क्यों या कैसे सत्यापित करें, क्या कहती हैं।
488
EN + हिं Easy
GB What is 'contextual inquiry' as a requirements elicitation technique and what unique insights does it produce?
IN आवश्यकताओं को प्राप्त करने की तकनीक के रूप में 'प्रासंगिक पूछताछ' क्या है और यह कौन सी अनूठी अंतर्दृष्टि उत्पन्न करती है?
A
Contextual inquiry is a technique where users complete online surveys about their software preferences प्रासंगिक पूछताछ एक ऐसी तकनीक है जहां उपयोगकर्ता अपनी सॉफ़्टवेयर प्राथमिकताओं के बारे में ऑनलाइन सर्वेक्षण पूरा करते हैं
B
Contextual inquiry involves observing users in their actual work environment while they perform real tasks — revealing workarounds, informal processes, environmental constraints, and tacit knowledge that users would never articulate in interviews प्रासंगिक जांच में उपयोगकर्ताओं को वास्तविक कार्य करते समय उनके वास्तविक कार्य वातावरण में देखना शामिल है - कामकाज, अनौपचारिक प्रक्रियाओं, पर्यावरणीय बाधाओं और मौन ज्ञान को प्रकट करना, जिसे उपयोगकर्ता कभी भी साक्षात्कार में व्यक्त नहीं करेंगे।
C
Contextual inquiry is a formal requirements review process involving only technical stakeholders प्रासंगिक जांच एक औपचारिक आवश्यकता समीक्षा प्रक्रिया है जिसमें केवल तकनीकी हितधारक शामिल होते हैं
D
Contextual inquiry is equivalent to a focus group and produces the same type of insights प्रासंगिक पूछताछ एक फोकस समूह के बराबर है और उसी प्रकार की अंतर्दृष्टि उत्पन्न करती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Contextual inquiry (Beyer and Holtzblatt) is based on the principle that people do not reliably describe how they actually work — they describe how they think they work or how they're supposed to work. Observation reveals: undocumented workarounds (existing systems can't do X so users maintain a spreadsheet), environmental constraints (noisy floor, multiple screens), and task flows very different from what IT documented.
व्याख्या (हिन्दी) प्रासंगिक जांच (बेयर और होल्ट्ज़ब्लैट) इस सिद्धांत पर आधारित है कि लोग विश्वसनीय रूप से यह नहीं बताते हैं कि वे वास्तव में कैसे काम करते हैं - वे वर्णन करते हैं कि वे कैसे सोचते हैं कि वे काम करते हैं या उन्हें कैसे काम करना चाहिए। अवलोकन से पता चलता है: अनिर्दिष्ट वर्कअराउंड (मौजूदा सिस्टम एक्स नहीं कर सकते हैं ताकि उपयोगकर्ता एक स्प्रेडशीट बनाए रखें), पर्यावरणीय बाधाएं (शोर फर्श, एकाधिक स्क्रीन), और कार्य प्रवाह आईटी द्वारा दस्तावेज से बहुत अलग है।
489
EN + हिं Easy
GB What is 'impact mapping' in requirements and product planning and what cascading relationship does it model?
IN आवश्यकताओं और उत्पाद योजना में 'प्रभाव मानचित्रण' क्या है और यह किस व्यापक संबंध का मॉडल तैयार करता है?
A
Impact mapping is a technique for measuring the financial impact of software defects इम्पैक्ट मैपिंग सॉफ्टवेयर दोषों के वित्तीय प्रभाव को मापने की एक तकनीक है
B
Impact mapping models the causal chain: WHY (business goal) → WHO (actors) → HOW (impacts on actors) → WHAT (deliverables/features) — preventing feature factories that deliver functionality disconnected from business outcomes प्रभाव मानचित्रण कारण श्रृंखला को मॉडल करता है: क्यों (व्यावसायिक लक्ष्य) → कौन (अभिनेता) → कैसे (अभिनेताओं पर प्रभाव) → क्या (डिलीवरेबल्स/फीचर्स) - व्यावसायिक परिणामों से अलग कार्यक्षमता प्रदान करने वाली फीचर फैक्ट्रियों को रोकना
C
Impact mapping is only used in marketing departments to measure advertising campaign effectiveness विज्ञापन अभियान की प्रभावशीलता को मापने के लिए प्रभाव मानचित्रण का उपयोग केवल विपणन विभागों में किया जाता है
D
Impact mapping replaces the product backlog by generating stories automatically from business goals प्रभाव मानचित्रण व्यावसायिक लक्ष्यों से स्वचालित रूप से कहानियाँ उत्पन्न करके उत्पाद बैकलॉग को प्रतिस्थापित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Gojko Adzic's impact mapping prevents the common failure of teams that deliver everything they were asked for but fail to achieve business goals. By requiring explicit causal links (this feature changes actor X's behaviour in way Y which achieves goal Z), impact mapping exposes features whose causal chain is weak — enabling ROI-based scope prioritisation.
व्याख्या (हिन्दी) गोज्को एडज़िक का प्रभाव मानचित्रण उन टीमों की सामान्य विफलता को रोकता है जो उनसे मांगी गई हर चीज़ प्रदान करती हैं लेकिन व्यावसायिक लक्ष्यों को प्राप्त करने में विफल रहती हैं। स्पष्ट कारण लिंक की आवश्यकता के द्वारा (यह सुविधा अभिनेता
490
EN + हिं Easy
GB What is the 'requirements inspection' process and what specific defect types does it target beyond what peer reviews find?
IN 'आवश्यकताओं के निरीक्षण' की प्रक्रिया क्या है और यह सहकर्मी समीक्षाओं से परे किस विशिष्ट दोष प्रकार को लक्षित करती है?
A
Requirements inspection only verifies that requirements are written in the mandated document format आवश्यकताएँ निरीक्षण केवल यह सत्यापित करता है कि आवश्यकताएँ अनिवार्य दस्तावेज़ प्रारूप में लिखी गई हैं
B
Requirements inspection applies Fagan-style checklists targeting requirements-specific defects: ambiguity (multiple interpretations), incompleteness (missing states/conditions), inconsistency (contradicting requirements), unverifiability (no testable criterion), and infeasibility आवश्यकताओं का निरीक्षण आवश्यकताओं-विशिष्ट दोषों को लक्षित करने वाली फगन-शैली चेकलिस्ट को लागू करता है: अस्पष्टता (एकाधिक व्याख्याएं), अपूर्णता (अनुपलब्ध राज्य/शर्तें), असंगतता (विरोधाभासी आवश्यकताएं), असत्यापनीयता (कोई परीक्षण योग्य मानदंड नहीं), और अव्यवहार्यता
C
Requirements inspection is identical to a requirements review; the terms are fully interchangeable आवश्यकताओं का निरीक्षण आवश्यकताओं की समीक्षा के समान है; शर्तें पूरी तरह से विनिमेय हैं
D
Requirements inspection can only be performed by external auditors, not internal team members आवश्यकताओं का निरीक्षण केवल बाहरी लेखा परीक्षकों द्वारा किया जा सकता है, आंतरिक टीम के सदस्यों द्वारा नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Requirements inspections use domain-specific checklists beyond what informal reviews catch. Ambiguity: 'the system shall respond quickly' — quickly meaning what? Incompleteness: what happens when input is null? Inconsistency: requirement 23 says X, requirement 47 says not-X. These are systematic defects invisible to the author but visible to trained inspectors examining against a checklist.
व्याख्या (हिन्दी) आवश्यकताएँ निरीक्षण अनौपचारिक समीक्षाओं से परे डोमेन-विशिष्ट चेकलिस्ट का उपयोग करते हैं। अस्पष्टता: 'सिस्टम तुरंत प्रतिक्रिया देगा' - त्वरित अर्थ क्या? अपूर्णता: क्या होता है जब इनपुट शून्य होता है? असंगति: आवश्यकता 23 कहती है एक्स, आवश्यकता 47 कहती है नॉट-एक्स। ये व्यवस्थित दोष हैं जो लेखक के लिए अदृश्य हैं लेकिन चेकलिस्ट के अनुसार जांच करने वाले प्रशिक्षित निरीक्षकों को दिखाई देते हैं।
491
EN + हिं Easy
GB What is the 'quality function deployment' (QFD) technique in requirements engineering and what does the 'house of quality' represent?
IN रिक्वायरमेंट इंजीनियरिंग में 'क्वालिटी फंक्शन डिप्लॉयमेंट' (क्यूएफडी) तकनीक क्या है और 'हाउस ऑफ क्वालिटी' क्या दर्शाती है?
A
QFD is a software testing technique ensuring quality attributes are defined before implementation क्यूएफडी एक सॉफ्टवेयर परीक्षण तकनीक है जो यह सुनिश्चित करती है कि कार्यान्वयन से पहले गुणवत्ता विशेषताओं को परिभाषित किया जाए
B
QFD (from manufacturing, applied to software) translates customer requirements (WHATs) into technical design characteristics (HOWs) via a correlation matrix — the 'house of quality' is this matrix showing which technical parameters satisfy which customer needs and their interactions क्यूएफडी (विनिर्माण से लेकर, सॉफ्टवेयर तक लागू) एक सहसंबंध मैट्रिक्स के माध्यम से ग्राहक आवश्यकताओं (डब्ल्यूएचएटीएस) को तकनीकी डिजाइन विशेषताओं (एचओडब्ल्यू) में अनुवादित करता है - 'गुणवत्ता का घर' यह मैट्रिक्स दिखाता है कि कौन से तकनीकी पैरामीटर ग्राहक की जरूरतों और उनकी बातचीत को पूरा करते हैं
C
QFD is a project management tool for tracking requirements completion percentages QFD आवश्यकताओं के पूरा होने के प्रतिशत पर नज़र रखने के लिए एक परियोजना प्रबंधन उपकरण है
D
QFD is only applicable to hardware product design, not software requirements QFD केवल हार्डवेयर उत्पाद डिज़ाइन पर लागू होता है, सॉफ़्टवेयर आवश्यकताओं पर नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) QFD's house of quality maps customer 'voices' (requirements) to engineering characteristics, showing relative importance weights, correlations between requirements, competing product benchmarks, and target values. Applied to software, it systematically connects user needs to design decisions, preventing designs that satisfy internal technical metrics while failing user needs — a common disconnect in software.
व्याख्या (हिन्दी) क्यूएफडी का हाउस ऑफ क्वालिटी ग्राहकों की आवाजों (आवश्यकताओं) को इंजीनियरिंग विशेषताओं के अनुसार मैप करता है, सापेक्ष महत्व के वजन, आवश्यकताओं के बीच संबंध, प्रतिस्पर्धी उत्पाद बेंचमार्क और लक्ष्य मूल्यों को दर्शाता है। सॉफ़्टवेयर पर लागू, यह डिज़ाइन निर्णयों के लिए उपयोगकर्ता की ज़रूरतों को व्यवस्थित रूप से जोड़ता है, ऐसे डिज़ाइनों को रोकता है जो उपयोगकर्ता की ज़रूरतों को विफल करते हुए आंतरिक तकनीकी मैट्रिक्स को पूरा करते हैं - सॉफ़्टवेयर में एक सामान्य डिस्कनेक्ट।
492
EN + हिं Medium
GB What is the difference between 'stated requirements', 'implied requirements', and 'latent requirements'?
IN 'कथित आवश्यकताओं', 'निहित आवश्यकताओं' और 'अव्यक्त आवश्यकताओं' के बीच क्या अंतर है?
A
All three terms describe the same category of requirements at different levels of documentation सभी तीन शब्द दस्तावेज़ीकरण के विभिन्न स्तरों पर आवश्यकताओं की समान श्रेणी का वर्णन करते हैं
B
Stated: explicitly requested by stakeholders; Implied: expected by convention but not stated (e.g., system should not lose data); Latent: unknown even to stakeholders until they experience a prototype — all three must be elicited for a complete system कहा गया: हितधारकों द्वारा स्पष्ट रूप से अनुरोध किया गया; निहित: सम्मेलन द्वारा अपेक्षित लेकिन बताया नहीं गया (उदाहरण के लिए, सिस्टम को डेटा नहीं खोना चाहिए); अव्यक्त: हितधारकों के लिए भी अज्ञात है जब तक कि वे एक प्रोटोटाइप का अनुभव नहीं करते हैं - इन तीनों को एक संपूर्ण प्रणाली के लिए प्राप्त किया जाना चाहिए
C
Stated requirements are formal; implied and latent are informal and should be excluded from SRS बताई गई आवश्यकताएँ औपचारिक हैं; निहित और अव्यक्त अनौपचारिक हैं और इन्हें एसआरएस से बाहर रखा जाना चाहिए
D
Latent requirements only arise from compliance and regulatory sources अव्यक्त आवश्यकताएँ केवल अनुपालन और नियामक स्रोतों से उत्पन्न होती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Kano model (applied to requirements) distinguishes: basic needs (implied — if absent, dissatisfied; if present, neutral); performance needs (stated — satisfaction proportional to fulfilment); and excitement needs (latent — unexpected delighters). Missing implied requirements causes product rejection; discovering latent requirements creates competitive differentiation. Effective elicitation must target all three categories.
व्याख्या (हिन्दी) कानो मॉडल (आवश्यकताओं पर लागू) अंतर करता है: बुनियादी ज़रूरतें (अंतर्निहित - यदि अनुपस्थित है, असंतुष्ट; यदि मौजूद है, तो तटस्थ); प्रदर्शन की आवश्यकताएं (बताया गया - पूर्ति के लिए आनुपातिक संतुष्टि); और उत्साह की आवश्यकताएं (अव्यक्त - अप्रत्याशित प्रसन्नता)। निहित आवश्यकताओं का अभाव उत्पाद अस्वीकृति का कारण बनता है; अव्यक्त आवश्यकताओं की खोज प्रतिस्पर्धी भेदभाव पैदा करती है। प्रभावी उद्बोधन को सभी तीन श्रेणियों को लक्षित करना चाहिए।
493
EN + हिं Easy
GB What is 'specification by example' (SBE) and what advantage does it offer over traditional requirement statements?
IN 'उदाहरण द्वारा विशिष्टता' (एसबीई) क्या है और यह पारंपरिक आवश्यकता विवरणों पर क्या लाभ प्रदान करता है?
A
SBE automatically generates code examples from natural language requirements एसबीई स्वचालित रूप से प्राकृतिक भाषा आवश्यकताओं से कोड उदाहरण उत्पन्न करता है
B
SBE describes requirements through concrete examples of desired system behaviour rather than abstract statements — concrete examples remove ambiguity, serve as acceptance tests, and create shared understanding across business and technical stakeholders एसबीई अमूर्त बयानों के बजाय वांछित सिस्टम व्यवहार के ठोस उदाहरणों के माध्यम से आवश्यकताओं का वर्णन करता है - ठोस उदाहरण अस्पष्टता को दूर करते हैं, स्वीकृति परीक्षण के रूप में कार्य करते हैं, और व्यापार और तकनीकी हितधारकों के बीच साझा समझ पैदा करते हैं।
C
SBE only works for data transformation requirements; it cannot describe user interface behaviour एसबीई केवल डेटा परिवर्तन आवश्यकताओं के लिए काम करता है; यह उपयोगकर्ता इंटरफ़ेस व्यवहार का वर्णन नहीं कर सकता
D
SBE is identical to use case specification with no practical difference in practice एसबीई उपयोग केस विनिर्देश के समान है और व्यवहार में कोई व्यावहारिक अंतर नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Gojko Adzic's SBE replaces vague requirement statements ('the system shall calculate tax correctly') with concrete examples ('given order $100 in CA, tax should be $8.75; given order $100 in OR, tax should be $0'). The concrete example is unambiguous, immediately testable as an acceptance criterion, and communicates the same requirement to both business stakeholders and developers without translation loss.
व्याख्या (हिन्दी) गोज्को एडज़िक का एसबीई अस्पष्ट आवश्यकता कथनों ('सिस्टम कर की सही गणना करेगा') को ठोस उदाहरणों से बदल देता है ('सीए में $100 का ऑर्डर दिया गया है, टैक्स $8.75 होना चाहिए; OR में ऑर्डर $100 दिया गया है, टैक्स $0 होना चाहिए')। ठोस उदाहरण स्पष्ट है, स्वीकृति मानदंड के रूप में तुरंत परीक्षण योग्य है, और अनुवाद हानि के बिना व्यावसायिक हितधारकों और डेवलपर्स दोनों को समान आवश्यकता बताता है।
494
EN + हिं Easy
GB What is the 'requirements conflict' problem in multi-stakeholder systems and what resolution strategies exist?
IN बहु-हितधारक प्रणालियों में 'आवश्यकताओं के टकराव' की समस्या क्या है और कौन सी समाधान रणनीतियाँ मौजूद हैं?
A
Requirements conflicts only occur when two stakeholders are from different departments आवश्यकताओं का टकराव तभी होता है जब दो हितधारक अलग-अलग विभागों से होते हैं
B
Requirements conflicts arise when stakeholders have incompatible needs (e.g., security vs usability, performance vs cost); resolutions include: negotiation to find compromise, creating priority rankings, architectural solutions satisfying both, or explicitly deferring one requirement आवश्यकताओं में टकराव तब उत्पन्न होता है जब हितधारकों की ज़रूरतें असंगत होती हैं (उदाहरण के लिए, सुरक्षा बनाम प्रयोज्यता, प्रदर्शन बनाम लागत); संकल्पों में शामिल हैं: समझौता खोजने के लिए बातचीत, प्राथमिकता रैंकिंग बनाना, दोनों को संतुष्ट करने वाले वास्तुशिल्प समाधान, या स्पष्ट रूप से एक आवश्यकता को स्थगित करना
C
Requirements conflicts are always resolvable by selecting the higher-authority stakeholder's requirement आवश्यकताओं के टकराव को हमेशा उच्च-प्राधिकरण हितधारक की आवश्यकता का चयन करके हल किया जा सकता है
D
Requirements conflicts indicate the project should be cancelled and restarted with fewer stakeholders आवश्यकताओं के टकराव से संकेत मिलता है कि परियोजना को रद्द कर दिया जाना चाहिए और कम हितधारकों के साथ फिर से शुरू किया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Security vs. usability is a classic conflict: strong passwords reduce usability; multi-factor authentication adds friction. Resolution strategies: negotiation (find acceptable balance), viewpoint-specific requirements (different security levels for different user roles), architectural patterns (secure defaults with streamlined UX), or explicit management decision to defer one in favour of the other with documented rationale.
व्याख्या (हिन्दी) सुरक्षा बनाम प्रयोज्यता एक क्लासिक संघर्ष है: मजबूत पासवर्ड प्रयोज्यता को कम करते हैं; बहु-कारक प्रमाणीकरण घर्षण जोड़ता है। समाधान रणनीतियाँ: बातचीत (स्वीकार्य संतुलन ढूँढना), दृष्टिकोण-विशिष्ट आवश्यकताएँ (विभिन्न उपयोगकर्ता भूमिकाओं के लिए अलग-अलग सुरक्षा स्तर), वास्तुशिल्प पैटर्न (सुव्यवस्थित यूएक्स के साथ सुरक्षित डिफ़ॉल्ट), या दस्तावेजी तर्क के साथ एक को दूसरे के पक्ष में टालने का स्पष्ट प्रबंधन निर्णय।
495
EN + हिं Easy
GB What is the 'requirements workshop' (JAD session) and what specific advantage does joint authoring provide?
IN 'आवश्यकताएँ कार्यशाला' (जेएडी सत्र) क्या है और संयुक्त संलेखन क्या विशिष्ट लाभ प्रदान करता है?
A
JAD sessions are mandatory legal reviews of requirements documents by compliance officers जेएडी सत्र अनुपालन अधिकारियों द्वारा आवश्यकताओं के दस्तावेजों की अनिवार्य कानूनी समीक्षा है
B
JAD (Joint Application Design) brings all stakeholders together in intensive structured workshops to jointly produce requirements — the joint authoring advantage is that conflicts surface and are resolved in real time rather than circulating documents with contradictory comments over weeks जेएडी (संयुक्त अनुप्रयोग डिजाइन) सभी हितधारकों को संयुक्त रूप से आवश्यकताओं को पूरा करने के लिए गहन संरचित कार्यशालाओं में एक साथ लाता है - संयुक्त लेखन का लाभ यह है कि विरोधाभासी टिप्पणियों के साथ दस्तावेजों को हफ्तों तक प्रसारित करने के बजाय संघर्ष सामने आते हैं और वास्तविक समय में हल हो जाते हैं।
C
JAD sessions replace all other requirements techniques and are sufficient alone for any project जेएडी सत्र अन्य सभी आवश्यकताओं की तकनीकों को प्रतिस्थापित करते हैं और किसी भी परियोजना के लिए अकेले पर्याप्त होते हैं
D
JAD sessions are only effective for projects with fewer than five stakeholders JAD सत्र केवल पाँच से कम हितधारकों वाली परियोजनाओं के लिए प्रभावी हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Traditional requirements gathering sends draft documents to stakeholders separately; each returns comments in isolation; contradictions emerge when comments are collated — requiring another round. JAD (IBM, 1977) assembles all stakeholders simultaneously with a trained facilitator. Conflicts surface immediately, are negotiated in the room, and consensus is recorded — compressing weeks of document cycles into days.
व्याख्या (हिन्दी) पारंपरिक आवश्यकताओं को एकत्रित करने से हितधारकों को अलग से मसौदा दस्तावेज़ भेजे जाते हैं; प्रत्येक व्यक्ति अलग-अलग टिप्पणियाँ लौटाता है; जब टिप्पणियों का मिलान किया जाता है तो विरोधाभास उभर कर सामने आते हैं - जिसके लिए एक और दौर की आवश्यकता होती है। जेएडी (आईबीएम, 1977) एक प्रशिक्षित सुविधाकर्ता के साथ सभी हितधारकों को एक साथ इकट्ठा करता है। संघर्ष तुरंत सामने आते हैं, कमरे में बातचीत की जाती है, और सर्वसम्मति दर्ज की जाती है - दस्तावेज़ चक्र के सप्ताहों को दिनों में संपीड़ित करना।
481–495 of 647