{ "quizTitle": "Systems Engineering – Test Your Knowledge (SE-TYK)", "questions": [ { "number": 1, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "System definition", "text": "According to INCOSE, which statement best describes a system?", "answers": [ "A collection of interacting elements that, as a whole, exhibits properties and behaviours that cannot be ascribed to the elements in isolation.", "A collection of interacting elements that work together toward a purpose, even if the whole has no properties beyond the sum of its parts.", "Any organized set of people, processes and technology that is managed under a single authority for a specific mission.", "Any physical or organizational item that can be uniquely identified and controlled, such as an individual document or component." ] }, "de": { "title": "Systemdefinition", "text": "Welche Aussage beschreibt gemäß INCOSE ein System am besten?", "answers": [ "Eine Ansammlung interagierender Elemente, die als Ganzes Eigenschaften und Verhaltensweisen aufweist, welche den Elementen in Isolation nicht zugeschrieben werden können.", "Eine Ansammlung interagierender Elemente, die auf einen Zweck hinarbeiten, selbst wenn das Ganze keine Eigenschaften über die Summe seiner Teile hinaus besitzt.", "Jede organisierte Gruppe von Menschen, Prozessen und Technologie, die für eine bestimmte Mission unter einer einzigen Autorität verwaltet wird.", "Jeder physische oder organisatorische Gegenstand, der eindeutig identifiziert und kontrolliert werden kann, wie etwa ein einzelnes Dokument oder eine Komponente." ] } }, { "number": 2, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Systems engineering (SE) definition", "text": "Which option best reflects the INCOSE definition of systems engineering (aligned with SEH5)?", "answers": [ "A transdisciplinary, integrative approach that applies systems principles and both technical and management methods to realize, use and retire engineered systems.", "An approach that coordinates technical disciplines to define requirements and architectures for complex systems, while leaving life cycle management to project management.", "A discipline that focuses on integrating hardware, software and human elements, mainly during the development and integration phases.", "A quality-control activity performed at the end of a project to check that the delivered system meets its acceptance criteria." ] }, "de": { "title": "Definition von Systems Engineering (SE)", "text": "Welche Option gibt die INCOSE-Definition von Systems Engineering (in Übereinstimmung mit SEH5) am besten wieder?", "answers": [ "Ein transdisziplinärer, integrativer Ansatz, der Systemprinzipien sowie sowohl technische als auch Managementmethoden anwendet, um technische Systeme zu realisieren, zu nutzen und außer Betrieb zu nehmen.", "Ein Ansatz, der technische Disziplinen koordiniert, um Anforderungen und Architekturen für komplexe Systeme zu definieren, während das Lebenszyklusmanagement dem Projektmanagement überlassen bleibt.", "Eine Disziplin, die sich auf die Integration von Hardware, Software und menschlichen Elementen konzentriert, hauptsächlich während der Entwicklungs- und Integrationsphasen.", "Eine Qualitätskontrolltätigkeit, die am Ende eines Projekts durchgeführt wird, um zu überprüfen, ob das gelieferte System seine Abnahmekriterien erfüllt." ] } }, { "number": 3, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "System of interest", "text": "What is the system of interest (SoI) in systems engineering?", "answers": [ "The system whose life cycle is the primary focus of engineering, management and decision-making activities.", "A system that is closely related to the project outcome and provides important supporting capabilities, but is not the main focus of the engineering effort.", "A subsystem or element selected for detailed design within a larger project, even if the overall system remains outside the scope.", "The entire commercial market in which the organization operates, including all customers and competitors." ] }, "de": { "title": "Betrachtungssystem", "text": "Was ist das Betrachtungssystem (System of Interest, SoI) im Systems Engineering?", "answers": [ "Das System, dessen Lebenszyklus im Mittelpunkt der Engineering-, Management- und Entscheidungsaktivitäten steht.", "Ein System, das eng mit dem Projektergebnis verbunden ist und wichtige unterstützende Fähigkeiten bereitstellt, aber nicht im Mittelpunkt des Engineering-Aufwands steht.", "Ein Teilsystem oder Element, das innerhalb eines größeren Projekts für den Detailentwurf ausgewählt wird, auch wenn das Gesamtsystem außerhalb des Betrachtungsumfangs bleibt.", "Der gesamte kommerzielle Markt, in dem die Organisation tätig ist, einschließlich aller Kunden und Wettbewerber." ] } }, { "number": 4, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "SEBoK;ISO_15288", "en": { "title": "System of systems characteristics", "text": "Which statements characterise a system of systems (SoS)?", "answers": [ "Its elements are operationally independent systems that can achieve useful missions on their own.", "They collaborate to provide capabilities that no individual constituent system can provide alone.", "All constituent systems are always under a single program manager with one unified budget and authority.", "Constituent systems have no independent operational utility and exist only to support the larger SoS." ] }, "de": { "title": "Merkmale eines Systems von Systemen", "text": "Welche Aussagen kennzeichnen ein System von Systemen (SoS)?", "answers": [ "Seine Elemente sind operativ unabhängige Systeme, die für sich genommen nützliche Missionen erfüllen können.", "Sie arbeiten zusammen, um Fähigkeiten bereitzustellen, die kein einzelnes Bestandteilsystem allein bereitstellen kann.", "Alle Bestandteilsysteme unterstehen stets einem einzigen Programmmanager mit einem einheitlichen Budget und einer einheitlichen Autorität.", "Bestandteilsysteme haben keinen eigenständigen operativen Nutzen und existieren nur, um das übergeordnete SoS zu unterstützen." ] } }, { "number": 5, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Stakeholder in systems engineering", "text": "Who is considered a stakeholder in systems engineering?", "answers": [ "Any person, group or organization that can influence the system, is influenced by it, or has a legitimate interest in it.", "Any organization that formally signs the contract for the system and provides the funding for its development.", "People who will directly operate or use the delivered system in its operational environment.", "Only regulatory bodies that issue approvals or certification for the system." ] }, "de": { "title": "Stakeholder im Systems Engineering", "text": "Wer gilt im Systems Engineering als Stakeholder?", "answers": [ "Jede Person, Gruppe oder Organisation, die das System beeinflussen kann, von ihm beeinflusst wird oder ein berechtigtes Interesse daran hat.", "Jede Organisation, die den Vertrag für das System formell unterzeichnet und die Finanzierung für dessen Entwicklung bereitstellt.", "Personen, die das ausgelieferte System in seiner Einsatzumgebung direkt bedienen oder nutzen werden.", "Ausschließlich Aufsichtsbehörden, die Zulassungen oder Zertifizierungen für das System erteilen." ] } }, { "number": 6, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Requirement definition", "text": "What best describes a requirement?", "answers": [ "A statement describing a needed function, performance level, constraint or quality that the system or a stakeholder must satisfy and that can be verified.", "A statement capturing what stakeholders say they want from the system, even if it has not yet been analysed, prioritised or made testable.", "A description of the internal solution, such as specific component choices and design details, that engineers plan to implement.", "Any high-level marketing or business slogan that describes the system’s value proposition to customers." ] }, "de": { "title": "Definition einer Anforderung", "text": "Was beschreibt eine Anforderung am besten?", "answers": [ "Eine Aussage, die eine benötigte Funktion, ein Leistungsniveau, eine Einschränkung oder eine Qualität beschreibt, die das System oder ein Stakeholder erfüllen muss und die verifizierbar ist.", "Eine Aussage, die erfasst, was Stakeholder von dem System zu wollen angeben, auch wenn sie noch nicht analysiert, priorisiert oder prüfbar gemacht wurde.", "Eine Beschreibung der internen Lösung, etwa spezifischer Komponentenauswahlen und Entwurfsdetails, die die Ingenieure umzusetzen planen.", "Ein beliebiger übergeordneter Marketing- oder Geschäftsslogan, der das Wertversprechen des Systems für die Kunden beschreibt." ] } }, { "number": 7, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Requirement vs design", "text": "How do requirements and design differ?", "answers": [ "Requirements express what the system shall do and how well, independent of a particular implementation.", "Design describes how the system will be implemented to satisfy the requirements within given constraints and trade-offs.", "Requirements and design become effectively interchangeable once the baseline is approved.", "Design is always completed before requirements are defined, to give stakeholders something concrete to respond to." ] }, "de": { "title": "Anforderung vs. Entwurf", "text": "Wie unterscheiden sich Anforderungen und Entwurf?", "answers": [ "Anforderungen drücken aus, was das System leisten soll und wie gut, unabhängig von einer bestimmten Umsetzung.", "Der Entwurf beschreibt, wie das System umgesetzt wird, um die Anforderungen innerhalb gegebener Randbedingungen und Trade-offs zu erfüllen.", "Anforderungen und Entwurf werden praktisch austauschbar, sobald die Baseline genehmigt ist.", "Der Entwurf wird stets vor der Definition der Anforderungen abgeschlossen, um den Stakeholdern etwas Konkretes zur Reaktion zu geben." ] } }, { "number": 8, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Verification vs validation", "text": "Which pairing is correct?", "answers": [ "Verification checks that the system has been built right with respect to specified requirements, using methods such as test, analysis and inspection.", "Validation checks that the right system has been built by confirming it meets stakeholder needs and intended use in its operational context.", "Verification and validation are identical activities that simply use different terminology in different organizations.", "Validation must always be completed before any verification is carried out on the system." ] }, "de": { "title": "Verifizierung versus Validierung", "text": "Welche Zuordnung ist korrekt?", "answers": [ "Die Verifizierung prüft, ob das System in Bezug auf die spezifizierten Anforderungen richtig gebaut wurde, wobei Methoden wie Test, Analyse und Inspektion verwendet werden.", "Die Validierung prüft, ob das richtige System gebaut wurde, indem bestätigt wird, dass es die Stakeholder-Bedürfnisse und den beabsichtigten Einsatz in seinem operativen Kontext erfüllt.", "Verifizierung und Validierung sind identische Aktivitäten, die in verschiedenen Organisationen lediglich unterschiedliche Terminologie verwenden.", "Die Validierung muss stets abgeschlossen sein, bevor irgendeine Verifizierung am System durchgeführt wird." ] } }, { "number": 9, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "System life cycle definition", "text": "What is a system life cycle?", "answers": [ "The progression of a system from initial idea and concept definition through development, operation, support and eventual retirement or disposal.", "The period from detailed design approval through production and initial deployment of the system into service.", "The time during which the system is in operation and being maintained, assuming concept and development are already completed.", "Only the scheduled set of project tasks and milestones captured in the project Gantt chart." ] }, "de": { "title": "Definition des Systemlebenszyklus", "text": "Was ist ein Systemlebenszyklus?", "answers": [ "Der Fortschritt eines Systems von der ersten Idee und Konzeptdefinition über Entwicklung, Betrieb, Unterstützung bis hin zur endgültigen Außerbetriebnahme oder Entsorgung.", "Der Zeitraum von der Freigabe des Detailentwurfs über die Produktion bis zur ersten Indienststellung des Systems.", "Der Zeitraum, in dem sich das System im Betrieb befindet und gewartet wird, unter der Annahme, dass Konzept und Entwicklung bereits abgeschlossen sind.", "Ausschließlich die geplante Menge an Projektaufgaben und Meilensteinen, die im Gantt-Diagramm des Projekts erfasst sind." ] } }, { "number": 10, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Life cycle stage", "text": "What is a stage in a life cycle model?", "answers": [ "A defined interval of the system life cycle associated with a particular set of objectives and a system state, normally concluded by a decision gate.", "A time window in the project schedule within which related activities and reviews are grouped, regardless of system state.", "A phase dominated by a specific engineering discipline, such as software coding or hardware integration, regardless of decision criteria.", "Only the financial periods when customer payments are made to the supplier under the contract." ] }, "de": { "title": "Lebenszyklusphase", "text": "Was ist eine Phase in einem Lebenszyklusmodell?", "answers": [ "Ein definiertes Intervall des Systemlebenszyklus, das mit einer bestimmten Menge von Zielen und einem Systemzustand verbunden ist und normalerweise durch ein Entscheidungsgate abgeschlossen wird.", "Ein Zeitfenster im Projektterminplan, innerhalb dessen zusammengehörige Tätigkeiten und Reviews gruppiert werden, unabhängig vom Systemzustand.", "Eine Phase, die von einer bestimmten Ingenieurdisziplin dominiert wird, etwa Softwareprogrammierung oder Hardware-Integration, unabhängig von Entscheidungskriterien.", "Nur die finanziellen Zeiträume, in denen im Rahmen des Vertrags Kundenzahlungen an den Lieferanten geleistet werden." ] } }, { "number": 11, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "System life cycle standard ISO/IEC/IEEE 15288 scope", "text": "What life cycle scope does ISO/IEC/IEEE 15288 cover?", "answers": [ "System life cycle processes spanning from concept definition through utilization, support, and retirement.", "Processes primarily addressing system development and production while leaving operation to other standards.", "Processes focused on the acquisition and supply phases of projects rather than technical engineering.", "A framework limited to software engineering activities that omit hardware and organizational aspects." ] }, "de": { "title": "Umfang des Systemlebenszyklus-Standards ISO/IEC/IEEE 15288", "text": "Welchen Lebenszyklusumfang deckt ISO/IEC/IEEE 15288 ab?", "answers": [ "Systemlebenszyklusprozesse von der Konzeptdefinition über Nutzung, Unterstützung bis hin zur Außerdienststellung.", "Prozesse, die vorrangig die Systementwicklung und -produktion behandeln, während der Betrieb anderen Standards überlassen wird.", "Prozesse, die sich auf die Beschaffungs- und Lieferphasen von Projekten konzentrieren statt auf das technische Engineering.", "Ein Rahmenwerk, das auf Softwareentwicklungsaktivitäten beschränkt ist und Hardware- sowie organisatorische Aspekte auslässt." ] } }, { "number": 12, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Life cycle models and their purpose", "text": "Why do we use system life cycle models?", "answers": [ "To structure the system’s evolution into defined stages that support planning, monitoring and management decisions.", "To organize project activities in a standard order to reduce uncertainty and ensure every project follows the same path.", "To control scope creep and rework by fixing requirements and plans before any implementation begins.", "To replace project management processes by defining all required activities automatically." ] }, "de": { "title": "Lebenszyklusmodelle und ihr Zweck", "text": "Warum verwenden wir Systemlebenszyklusmodelle?", "answers": [ "Um die Entwicklung des Systems in definierte Phasen zu strukturieren, die Planung, Überwachung und Managemententscheidungen unterstützen.", "Um Projektaktivitäten in einer standardisierten Reihenfolge zu organisieren, um Unsicherheit zu reduzieren und sicherzustellen, dass jedes Projekt demselben Pfad folgt.", "Um Umfangsausweitung und Nacharbeit zu kontrollieren, indem Anforderungen und Pläne festgelegt werden, bevor mit der Umsetzung begonnen wird.", "Um Projektmanagementprozesse zu ersetzen, indem alle erforderlichen Aktivitäten automatisch definiert werden." ] } }, { "number": 13, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Emergent properties of systems", "text": "What is meant by emergent properties of a system?", "answers": [ "Properties that result from interactions among system elements and are meaningful only when considering the system as a whole.", "Properties that can be predicted from the properties of individual components once those are well characterized.", "Behavioural effects caused only by external environmental factors rather than internal interactions.", "Observable properties of each component considered separately from the rest of the system." ] }, "de": { "title": "Emergente Eigenschaften von Systemen", "text": "Was versteht man unter emergenten Eigenschaften eines Systems?", "answers": [ "Eigenschaften, die aus den Wechselwirkungen zwischen Systemelementen resultieren und nur bei Betrachtung des Systems als Ganzes sinnvoll sind.", "Eigenschaften, die aus den Eigenschaften einzelner Komponenten vorhergesagt werden können, sobald diese gut charakterisiert sind.", "Verhaltenseffekte, die ausschließlich durch äußere Umgebungsfaktoren und nicht durch interne Wechselwirkungen verursacht werden.", "Beobachtbare Eigenschaften jeder Komponente, betrachtet getrennt vom Rest des Systems." ] } }, { "number": 14, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Enabling systems", "text": "Which best describes an enabling system?", "answers": [ "A system that provides services needed by the system of interest during one or more life-cycle stages (e.g., production, maintenance, training) without being part of the delivered system.", "A supporting system that interacts with the system of interest mainly during operations but may occasionally contribute in other stages.", "A related system that performs functions similar to the system of interest but with different performance levels or missions.", "A system that must always be delivered together with the system of interest as part of the same operational configuration." ] }, "de": { "title": "Unterstützende Systeme (Enabling Systems)", "text": "Was beschreibt ein unterstützendes System (Enabling System) am besten?", "answers": [ "Ein System, das Dienste bereitstellt, die das betrachtete System während einer oder mehrerer Lebenszyklusphasen benötigt (z. B. Produktion, Wartung, Schulung), ohne Teil des gelieferten Systems zu sein.", "Ein unterstützendes System, das hauptsächlich während des Betriebs mit dem betrachteten System interagiert, aber gelegentlich auch in anderen Phasen beitragen kann.", "Ein verwandtes System, das ähnliche Funktionen wie das betrachtete System erfüllt, jedoch mit unterschiedlichen Leistungsniveaus oder Missionen.", "Ein System, das stets zusammen mit dem betrachteten System als Teil derselben betrieblichen Konfiguration geliefert werden muss." ] } }, { "number": 15, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Operation process focus (ISO 15288)", "text": "What is the focus of the operation process?", "answers": [ "Using the system in its intended operational environment to deliver the required services to stakeholders.", "Coordinating operator training, user support and data collection to sustain the system’s availability.", "Managing the transition of the system from development to operations, including early acceptance activities.", "Performing end-of-life disposal and decommissioning actions when the system is no longer required." ] }, "de": { "title": "Fokus des Betriebsprozesses (ISO 15288)", "text": "Worauf liegt der Fokus des Betriebsprozesses?", "answers": [ "Nutzung des Systems in seiner vorgesehenen Betriebsumgebung, um den Stakeholdern die geforderten Leistungen bereitzustellen.", "Koordination der Bedienerschulung, des Benutzersupports und der Datenerfassung, um die Verfügbarkeit des Systems aufrechtzuerhalten.", "Steuerung des Übergangs des Systems von der Entwicklung in den Betrieb, einschließlich früher Abnahmeaktivitäten.", "Durchführung von Entsorgungs- und Außerbetriebnahmemaßnahmen am Lebensende, wenn das System nicht mehr benötigt wird." ] } }, { "number": 16, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Disposal process focus", "text": "What is the focus of the disposal process?", "answers": [ "Planned and safe removal, recycling or destruction of system elements at end of life.", "Preparation of disposal strategies and environmental plans during system design, without actual execution.", "Execution of maintenance activities that prolong service life until the system naturally becomes obsolete.", "Routine operations performed to support users and maintain availability." ] }, "de": { "title": "Schwerpunkt des Entsorgungsprozesses", "text": "Was ist der Schwerpunkt des Entsorgungsprozesses?", "answers": [ "Geplante und sichere Entfernung, Wiederverwertung oder Zerstörung von Systemelementen am Ende ihrer Lebensdauer.", "Vorbereitung von Entsorgungsstrategien und Umweltplänen während des Systementwurfs, ohne tatsächliche Ausführung.", "Durchführung von Wartungsaktivitäten, die die Nutzungsdauer verlängern, bis das System auf natürliche Weise veraltet.", "Routinemäßige Betriebstätigkeiten, die durchgeführt werden, um Nutzer zu unterstützen und die Verfügbarkeit aufrechtzuerhalten." ] } }, { "number": 17, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Configuration baselines", "text": "Which are typical systems engineering baselines?", "answers": [ "Requirements baseline, allocated baseline and product (as-built) baseline.", "Functional baseline, allocated baseline and verified baseline used for production release.", "Concept baseline, integration baseline and validation baseline defined by each organization.", "A single evolving baseline that is continuously updated instead of controlled at major milestones." ] }, "de": { "title": "Konfigurations-Baselines", "text": "Welche sind typische Systems-Engineering-Baselines?", "answers": [ "Anforderungs-Baseline, zugewiesene Baseline (allocated baseline) und Produkt-Baseline (as-built).", "Funktionale Baseline, zugewiesene Baseline und verifizierte Baseline, die für die Produktionsfreigabe verwendet werden.", "Konzept-Baseline, Integrations-Baseline und Validierungs-Baseline, die von jeder Organisation definiert werden.", "Eine einzige sich entwickelnde Baseline, die kontinuierlich aktualisiert statt an wichtigen Meilensteinen kontrolliert wird." ] } }, { "number": 18, "correct": [ 0, 1, 2 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "ISO 15288 process groups", "text": "Which are the four process groups defined in ISO/IEC/IEEE 15288?", "answers": [ "Agreement processes.", "Organizational project-enabling processes.", "Technical management processes and technical processes.", "Hardware, software, human and service processes." ] }, "de": { "title": "Prozessgruppen der ISO 15288", "text": "Welches sind die vier in ISO/IEC/IEEE 15288 definierten Prozessgruppen?", "answers": [ "Vereinbarungsprozesse.", "Organisatorische projektunterstützende Prozesse.", "Technische Managementprozesse und technische Prozesse.", "Hardware-, Software-, Menschen- und Dienstleistungsprozesse." ] } }, { "number": 19, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Agreement process group", "text": "Which processes belong to the agreement process group in ISO 15288?", "answers": [ "Acquisition.", "Supply.", "Stakeholder requirements definition.", "Integration." ] }, "de": { "title": "Vereinbarungsprozessgruppe", "text": "Welche Prozesse gehören in ISO 15288 zur Vereinbarungsprozessgruppe (Agreement Process Group)?", "answers": [ "Beschaffung.", "Lieferung.", "Definition der Stakeholder-Anforderungen.", "Integration." ] } }, { "number": 20, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Organizational project-enabling processes", "text": "Which are examples of organizational project-enabling processes?", "answers": [ "Life cycle model management and infrastructure management.", "Quality management and knowledge management.", "System architecture definition and design definition.", "Transition and operation." ] }, "de": { "title": "Organisatorische projektermöglichende Prozesse", "text": "Welche sind Beispiele für organisatorische projektermöglichende Prozesse?", "answers": [ "Lebenszyklusmodell-Management und Infrastrukturmanagement.", "Qualitätsmanagement und Wissensmanagement.", "Systemarchitekturdefinition und Entwurfsdefinition.", "Überführung und Betrieb." ] } }, { "number": 21, "correct": [ 0, 1, 2 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Technical management processes", "text": "Which are technical management processes according to ISO/IEC/IEEE 15288?", "answers": [ "Project planning and project assessment and control.", "Risk management and configuration management.", "Measurement and information management.", "System implementation and integration." ] }, "de": { "title": "Technische Managementprozesse", "text": "Welche sind technische Managementprozesse gemäß ISO/IEC/IEEE 15288?", "answers": [ "Projektplanung sowie Projektbewertung und -steuerung.", "Risikomanagement und Konfigurationsmanagement.", "Messung und Informationsmanagement.", "Systemimplementierung und -integration." ] } }, { "number": 22, "correct": [ 0, 1, 2 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Technical processes", "text": "Which are technical processes according to ISO/IEC/IEEE 15288?", "answers": [ "Business or mission analysis.", "Stakeholder needs and requirements definition.", "System requirements definition, architecture definition and design definition.", "Portfolio management and enterprise strategy planning." ] }, "de": { "title": "Technische Prozesse", "text": "Welches sind technische Prozesse gemäß ISO/IEC/IEEE 15288?", "answers": [ "Geschäfts- oder Missionsanalyse.", "Definition der Stakeholder-Bedürfnisse und -Anforderungen.", "Definition der Systemanforderungen, Architekturdefinition und Entwurfsdefinition.", "Portfoliomanagement und Unternehmensstrategieplanung." ] } }, { "number": 23, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Acquisition process purpose", "text": "Main purpose of the acquisition process is?", "answers": [ "To obtain a system or service from a supplier, under an agreement, that satisfies the acquirer’s defined needs.", "To define and manage the contractual relationship between acquirer and supplier, focusing mainly on terms and conditions.", "To coordinate procurement activities and ensure that selected suppliers can deliver capabilities aligned with business objectives.", "To define human-resource policies and employment contracts for all staff in the organization." ] }, "de": { "title": "Zweck des Beschaffungsprozesses", "text": "Der Hauptzweck des Beschaffungsprozesses ist?", "answers": [ "Ein System oder eine Dienstleistung von einem Lieferanten im Rahmen einer Vereinbarung zu beziehen, das bzw. die die definierten Bedürfnisse des Auftraggebers erfüllt.", "Die vertragliche Beziehung zwischen Auftraggeber und Lieferant zu definieren und zu steuern, mit Schwerpunkt auf den Vertragsbedingungen.", "Beschaffungsaktivitäten zu koordinieren und sicherzustellen, dass ausgewählte Lieferanten Fähigkeiten liefern können, die auf die Geschäftsziele ausgerichtet sind.", "Personalrichtlinien und Arbeitsverträge für alle Mitarbeitenden der Organisation zu definieren." ] } }, { "number": 24, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Supply process", "text": "What does the supply process address?", "answers": [ "Preparing, negotiating and fulfilling an agreement to provide a system or service to an acquirer.", "Managing the supplier’s internal development, manufacturing and test activities once the contract has been signed.", "Coordinating contract deliverables and acceptance events defined in the statement of work.", "Defining stakeholder needs for internal research and development projects unrelated to any external customer." ] }, "de": { "title": "Lieferprozess", "text": "Was behandelt der Lieferprozess?", "answers": [ "Vorbereitung, Verhandlung und Erfüllung einer Vereinbarung zur Bereitstellung eines Systems oder einer Dienstleistung an einen Erwerber.", "Steuerung der internen Entwicklungs-, Fertigungs- und Testaktivitäten des Lieferanten, sobald der Vertrag unterzeichnet wurde.", "Koordinierung der im Leistungsverzeichnis definierten Vertragsleistungen und Abnahmeereignisse.", "Definition von Stakeholder-Bedürfnissen für interne Forschungs- und Entwicklungsprojekte, die keinen Bezug zu einem externen Kunden haben." ] } }, { "number": 25, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Life cycle model management", "text": "Goal of life cycle model management?", "answers": [ "To define, maintain and improve the set of life cycle models used across the organization’s projects.", "To recommend default project phases and reviews that individual projects may tailor for their specific needs.", "To capture lessons learned from projects and feed them into updates of selected organizational processes.", "To negotiate and sign all supplier contracts on behalf of the organization’s projects." ] }, "de": { "title": "Management von Lebenszyklusmodellen", "text": "Ziel des Managements von Lebenszyklusmodellen?", "answers": [ "Die Menge der in den Projekten der Organisation verwendeten Lebenszyklusmodelle zu definieren, zu pflegen und zu verbessern.", "Standardmäßige Projektphasen und Reviews zu empfehlen, die einzelne Projekte an ihre spezifischen Bedürfnisse anpassen können.", "Erkenntnisse (Lessons Learned) aus Projekten zu erfassen und in die Aktualisierung ausgewählter organisatorischer Prozesse einfließen zu lassen.", "Alle Lieferantenverträge im Namen der Projekte der Organisation auszuhandeln und zu unterzeichnen." ] } }, { "number": 26, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288;SEBoK", "en": { "title": "Quality management vs quality assurance", "text": "How do quality management and quality assurance relate?", "answers": [ "Quality management defines quality policies and objectives, while quality assurance provides evidence and activities to demonstrate those objectives are being met.", "Quality management and quality assurance both aim to ensure product and process quality, with management emphasising planning and assurance emphasising verification.", "Quality management mainly addresses manufacturing activities, whereas quality assurance is primarily associated with design reviews.", "Quality assurance replaces the need for technical reviews or verification activities because it focuses on final product checks." ] }, "de": { "title": "Qualitätsmanagement versus Qualitätssicherung", "text": "In welchem Verhältnis stehen Qualitätsmanagement und Qualitätssicherung zueinander?", "answers": [ "Das Qualitätsmanagement definiert Qualitätsleitlinien und -ziele, während die Qualitätssicherung Nachweise und Tätigkeiten bereitstellt, um zu belegen, dass diese Ziele erreicht werden.", "Qualitätsmanagement und Qualitätssicherung zielen beide darauf ab, Produkt- und Prozessqualität sicherzustellen, wobei das Management die Planung und die Sicherung die Verifizierung betont.", "Das Qualitätsmanagement befasst sich hauptsächlich mit Fertigungstätigkeiten, während die Qualitätssicherung vorrangig mit Entwurfs-Reviews verbunden ist.", "Die Qualitätssicherung ersetzt die Notwendigkeit technischer Reviews oder Verifizierungstätigkeiten, da sie sich auf Endproduktprüfungen konzentriert." ] } }, { "number": 27, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Knowledge management", "text": "What is a key outcome of knowledge management?", "answers": [ "Key organizational knowledge is captured, organized, shared and reused across projects and teams.", "Collecting and storing project documentation such as risk registers and lessons learned in common repositories.", "Documenting staff competencies and roles so that expertise can be located when needed.", "Maintaining only lists of supplier contact details and phone numbers." ] }, "de": { "title": "Wissensmanagement", "text": "Was ist ein zentrales Ergebnis des Wissensmanagements?", "answers": [ "Zentrales organisatorisches Wissen wird erfasst, strukturiert, geteilt und projekt- und teamübergreifend wiederverwendet.", "Erfassung und Speicherung von Projektdokumentation wie Risikoregistern und Lessons Learned in gemeinsamen Ablagen.", "Dokumentation von Kompetenzen und Rollen der Mitarbeitenden, damit Fachwissen bei Bedarf auffindbar ist.", "Führung ausschließlich von Listen mit Kontaktdaten und Telefonnummern der Lieferanten." ] } }, { "number": 28, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288;INCOSE_SEH5", "en": { "title": "Project planning outputs", "text": "Key outputs of project planning include:", "answers": [ "Integrated plans that cover project scope, schedule, resources and the technical approach.", "High-level technical and management plans that identify major milestones and responsibilities.", "Detailed verification and validation plans developed early enough to influence scheduling and resource decisions.", "Only documentation describing exactly what was built after the project has been completed." ] }, "de": { "title": "Ergebnisse der Projektplanung", "text": "Zu den wesentlichen Ergebnissen der Projektplanung gehören:", "answers": [ "Integrierte Pläne, die den Projektumfang, den Zeitplan, die Ressourcen und den technischen Ansatz abdecken.", "Übergeordnete technische und Managementpläne, die wesentliche Meilensteine und Verantwortlichkeiten festlegen.", "Detaillierte Verifizierungs- und Validierungspläne, die früh genug entwickelt werden, um Zeitplanungs- und Ressourcenentscheidungen zu beeinflussen.", "Ausschließlich Dokumentation, die genau beschreibt, was nach Abschluss des Projekts gebaut wurde." ] } }, { "number": 29, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Project assessment and control", "text": "Purpose of project assessment and control is:", "answers": [ "To determine actual project status and direct corrective or preventive actions needed to meet agreed objectives.", "To periodically review technical results and progress indicators to judge whether the project remains aligned with its baselines.", "To assess whether scope, cost or schedule baselines should be adjusted in response to identified issues.", "To carry out physical maintenance on deployed systems instead of monitoring project progress." ] }, "de": { "title": "Projektbewertung und -steuerung", "text": "Der Zweck der Projektbewertung und -steuerung ist:", "answers": [ "Den tatsächlichen Projektstatus zu ermitteln und die zur Erreichung der vereinbarten Ziele erforderlichen korrigierenden oder vorbeugenden Maßnahmen zu steuern.", "Technische Ergebnisse und Fortschrittsindikatoren regelmäßig zu überprüfen, um zu beurteilen, ob das Projekt mit seinen Baselines übereinstimmt.", "Zu bewerten, ob die Baselines für Umfang, Kosten oder Termine als Reaktion auf identifizierte Probleme angepasst werden sollten.", "Physische Wartung an eingesetzten Systemen durchzuführen, anstatt den Projektfortschritt zu überwachen." ] } }, { "number": 30, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Risk management", "text": "Core risk management activities are:", "answers": [ "Risk identification and analysis.", "Risk treatment planning and monitoring.", "Identifying configuration items that might fail and tracking them as risks without further analysis.", "Running normal operations and monitoring performance without performing explicit risk management." ] }, "de": { "title": "Risikomanagement", "text": "Die zentralen Tätigkeiten des Risikomanagements sind:", "answers": [ "Risikoidentifikation und -analyse.", "Planung und Überwachung der Risikobehandlung.", "Identifizierung von Konfigurationseinheiten, die ausfallen könnten, und deren Verfolgung als Risiken ohne weitere Analyse.", "Durchführung des Normalbetriebs und Überwachung der Leistung, ohne ein explizites Risikomanagement durchzuführen." ] } }, { "number": 31, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "ISO_15288;INCOSE_SEH5", "en": { "title": "Configuration management", "text": "Key objectives of configuration management are:", "answers": [ "Identify configuration items and control changes to them.", "Record and report configuration status and verify configurations against requirements and baselines.", "Eliminate most documentation by keeping all decisions in informal team discussions.", "Ensure that once a design is approved it can never be changed under any circumstances." ] }, "de": { "title": "Konfigurationsmanagement", "text": "Zentrale Ziele des Konfigurationsmanagements sind:", "answers": [ "Konfigurationseinheiten identifizieren und Änderungen an ihnen kontrollieren.", "Konfigurationsstatus erfassen und berichten sowie Konfigurationen gegen Anforderungen und Baselines verifizieren.", "Den Großteil der Dokumentation eliminieren, indem alle Entscheidungen in informellen Teamgesprächen gehalten werden.", "Sicherstellen, dass ein einmal genehmigter Entwurf unter keinen Umständen jemals geändert werden kann." ] } }, { "number": 32, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Decision management", "text": "What does decision management focus on?", "answers": [ "Using a defined decision process with explicit criteria and alternatives to select courses of action.", "Supporting management choices by presenting options and their main pros and cons, even if criteria are not fully formalised.", "Facilitating workshops where stakeholders discuss and negotiate to reach consensus on preferred options.", "Operating the system in the field according to predefined procedures and instructions." ] }, "de": { "title": "Entscheidungsmanagement", "text": "Worauf konzentriert sich das Entscheidungsmanagement?", "answers": [ "Verwendung eines definierten Entscheidungsprozesses mit expliziten Kriterien und Alternativen, um Handlungsoptionen auszuwählen.", "Unterstützung von Managemententscheidungen durch die Darstellung von Optionen und ihren wesentlichen Vor- und Nachteilen, auch wenn die Kriterien nicht vollständig formalisiert sind.", "Moderation von Workshops, in denen Stakeholder diskutieren und verhandeln, um Konsens über bevorzugte Optionen zu erzielen.", "Betrieb des Systems im Feld gemäß vordefinierten Verfahren und Anweisungen." ] } }, { "number": 33, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Information management", "text": "Purpose of information management is:", "answers": [ "Ensuring that information is captured, stored, controlled and distributed appropriately throughout the system life cycle.", "Maintaining common repositories for project records and technical documents accessible to relevant stakeholders.", "Managing data archives separately from configuration items so that historical information is preserved when designs change.", "Deliberately ignoring information needs of external stakeholders to keep information flows simple." ] }, "de": { "title": "Informationsmanagement", "text": "Der Zweck des Informationsmanagements ist:", "answers": [ "Sicherzustellen, dass Informationen während des gesamten Systemlebenszyklus angemessen erfasst, gespeichert, kontrolliert und verteilt werden.", "Gemeinsame Ablagen für Projektaufzeichnungen und technische Dokumente zu pflegen, die den relevanten Stakeholdern zugänglich sind.", "Datenarchive getrennt von Konfigurationseinheiten zu verwalten, sodass historische Informationen erhalten bleiben, wenn sich Entwürfe ändern.", "Die Informationsbedürfnisse externer Stakeholder bewusst zu ignorieren, um die Informationsflüsse einfach zu halten." ] } }, { "number": 34, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288;SEBoK", "en": { "title": "Measurement process", "text": "Purpose of the measurement process is:", "answers": [ "Collecting, analysing and using quantitative measures to support management and technical decisions.", "Gathering performance data from tests and operations to provide trend charts and status dashboards.", "Defining a set of metrics and thresholds primarily to demonstrate compliance with organizational policies.", "Updating human-resource policies based solely on informal impressions rather than any quantitative indicators." ] }, "de": { "title": "Messprozess", "text": "Der Zweck des Messprozesses ist:", "answers": [ "Das Erheben, Analysieren und Nutzen quantitativer Messgrößen zur Unterstützung von Management- und technischen Entscheidungen.", "Das Sammeln von Leistungsdaten aus Tests und Betrieb, um Trenddiagramme und Status-Dashboards bereitzustellen.", "Das Festlegen einer Menge von Metriken und Schwellenwerten, hauptsächlich um die Einhaltung organisatorischer Leitlinien nachzuweisen.", "Das Aktualisieren von Personalrichtlinien ausschließlich auf Basis informeller Eindrücke statt anhand quantitativer Indikatoren." ] } }, { "number": 35, "correct": [ 0, 3 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Systems engineering (SE) vs project management (PM)", "text": "How do systems engineering and project management relate?", "answers": [ "They are distinct but tightly coupled disciplines that must be integrated to be effective.", "SE is a subset of PM with no special technical content or responsibilities.", "PM is unnecessary if SE is applied rigorously throughout the project life cycle.", "Both share responsibility for balancing scope, cost, schedule and technical performance, even though they emphasise different aspects." ] }, "de": { "title": "Systems Engineering (SE) vs. Projektmanagement (PM)", "text": "In welcher Beziehung stehen Systems Engineering und Projektmanagement zueinander?", "answers": [ "Sie sind eigenständige, aber eng gekoppelte Disziplinen, die integriert werden müssen, um wirksam zu sein.", "SE ist eine Teilmenge des PM ohne besondere technische Inhalte oder Verantwortlichkeiten.", "PM ist überflüssig, wenn SE über den gesamten Projektlebenszyklus konsequent angewendet wird.", "Beide teilen sich die Verantwortung für die Abwägung von Umfang, Kosten, Terminen und technischer Leistung, auch wenn sie unterschiedliche Aspekte betonen." ] } }, { "number": 36, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288;INCOSE_SEH5", "en": { "title": "Business or mission analysis", "text": "Purpose of business or mission analysis is:", "answers": [ "Analysing mission or business needs and defining candidate solution concepts to address them.", "Reviewing current operations to identify inefficiencies and potential opportunities for improvement.", "Preparing preliminary cost–benefit assessments to judge whether a new capability might be justified.", "Performing day-to-day production and disposal tasks unrelated to mission definition." ] }, "de": { "title": "Geschäfts- oder Missionsanalyse", "text": "Der Zweck der Geschäfts- oder Missionsanalyse ist:", "answers": [ "Analyse von Missions- oder Geschäftsbedürfnissen und Definition von Lösungskandidatenkonzepten, um diese zu adressieren.", "Überprüfung des aktuellen Betriebs, um Ineffizienzen und potenzielle Verbesserungsmöglichkeiten zu identifizieren.", "Erstellung vorläufiger Kosten-Nutzen-Bewertungen, um zu beurteilen, ob eine neue Fähigkeit gerechtfertigt sein könnte.", "Durchführung alltäglicher Produktions- und Entsorgungsaufgaben, die keinen Bezug zur Missionsdefinition haben." ] } }, { "number": 37, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Stakeholder needs vs system requirements", "text": "How are stakeholder needs and system requirements related?", "answers": [ "Stakeholder needs are analysed, refined and transformed into system requirements through defined systems engineering processes.", "They often use similar wording and, in small projects, may be recorded in the same documents even if conceptually distinct.", "System requirements may be drafted early and then refined as stakeholder needs are better understood over time.", "Stakeholder needs are documented only during the operations phase, after development has been completed." ] }, "de": { "title": "Stakeholder-Bedürfnisse vs. Systemanforderungen", "text": "In welcher Beziehung stehen Stakeholder-Bedürfnisse und Systemanforderungen?", "answers": [ "Stakeholder-Bedürfnisse werden durch definierte Systems-Engineering-Prozesse analysiert, verfeinert und in Systemanforderungen überführt.", "Sie verwenden oft eine ähnliche Formulierung und können in kleinen Projekten in denselben Dokumenten erfasst werden, auch wenn sie konzeptionell verschieden sind.", "Systemanforderungen können früh entworfen und anschließend verfeinert werden, sobald die Stakeholder-Bedürfnisse im Laufe der Zeit besser verstanden werden.", "Stakeholder-Bedürfnisse werden erst während der Betriebsphase dokumentiert, nachdem die Entwicklung abgeschlossen ist." ] } }, { "number": 38, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Good requirements", "text": "Which attributes describe good individual requirements?", "answers": [ "They are correct, clear, verifiable, feasible and truly necessary for the system.", "They should allow reasonable design freedom, so some degree of generality is acceptable if supported by clarifying constraints.", "Grouping closely related constraints in a single statement can be acceptable as long as each is still testable and unambiguous.", "Allowing contradictory expectations in the same statement so that trade-offs can be discussed later in design reviews." ] }, "de": { "title": "Gute Anforderungen", "text": "Welche Attribute beschreiben gute einzelne Anforderungen?", "answers": [ "Sie sind korrekt, klar, verifizierbar, umsetzbar und für das System tatsächlich notwendig.", "Sie sollten angemessene Entwurfsfreiheit zulassen, sodass ein gewisses Maß an Allgemeinheit akzeptabel ist, wenn es durch klärende Einschränkungen gestützt wird.", "Das Zusammenfassen eng verwandter Einschränkungen in einer einzigen Aussage kann akzeptabel sein, solange jede weiterhin prüfbar und eindeutig ist.", "Das Zulassen widersprüchlicher Erwartungen in derselben Aussage, sodass Trade-offs später in Entwurfs-Reviews erörtert werden können." ] } }, { "number": 39, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Bidirectional traceability", "text": "Why is bidirectional traceability important?", "answers": [ "It demonstrates that each requirement has a justified source and can be traced to its implementation and verification evidence.", "It can speed up impact analysis because linked artefacts indicate which parts of the system may need to change.", "It helps identify which stakeholders are associated with particular requirements for communication and negotiation purposes.", "It is used primarily instead of documenting design decisions and rationale in a structured way." ] }, "de": { "title": "Bidirektionale Nachverfolgbarkeit", "text": "Warum ist die bidirektionale Nachverfolgbarkeit wichtig?", "answers": [ "Sie belegt, dass jede Anforderung eine begründete Quelle hat und bis zu ihrer Umsetzung und ihrem Verifizierungsnachweis nachverfolgt werden kann.", "Sie kann die Auswirkungsanalyse beschleunigen, da verknüpfte Artefakte anzeigen, welche Teile des Systems möglicherweise geändert werden müssen.", "Sie hilft zu erkennen, welche Stakeholder zu bestimmten Anforderungen gehören, für Zwecke der Kommunikation und Verhandlung.", "Sie wird vorrangig anstelle einer strukturierten Dokumentation von Entwurfsentscheidungen und deren Begründung verwendet." ] } }, { "number": 40, "correct": [ 0, 1, 2 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Verification methods", "text": "Which are standard verification methods?", "answers": [ "Test.", "Analysis.", "Inspection, demonstration or formal review.", "Ad hoc guessing about whether the system works as intended." ] }, "de": { "title": "Verifizierungsmethoden", "text": "Welche sind Standard-Verifizierungsmethoden?", "answers": [ "Test.", "Analyse.", "Inspektion, Demonstration oder formale Überprüfung.", "Ad-hoc-Raten darüber, ob das System wie beabsichtigt funktioniert." ] } }, { "number": 41, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "SEBoK;INCOSE_SEH5", "en": { "title": "Quality characteristics (non-functional requirements)", "text": "Which statements about quality characteristics (non functional requirements) are correct?", "answers": [ "They express quality characteristics such as reliability, safety and usability.", "They can strongly influence architecture trade-offs and design choices.", "They are optional if the delivery schedule is very tight.", "They are written only after coding and implementation are completed." ] }, "de": { "title": "Qualitätsmerkmale (nichtfunktionale Anforderungen)", "text": "Welche Aussagen über Qualitätsmerkmale (nichtfunktionale Anforderungen) sind korrekt?", "answers": [ "Sie drücken Qualitätsmerkmale wie Zuverlässigkeit, Sicherheit und Gebrauchstauglichkeit aus.", "Sie können Architektur-Trade-offs und Entwurfsentscheidungen stark beeinflussen.", "Sie sind optional, wenn der Lieferzeitplan sehr eng ist.", "Sie werden erst nach Abschluss der Codierung und Implementierung geschrieben." ] } }, { "number": 42, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;NASA_SEH", "en": { "title": "Concept of Operations (CONOPS)", "text": "Purpose of a Concept of Operations (CONOPS)?", "answers": [ "To describe how the system will be used in its operational context from the perspective of users and other stakeholders.", "To outline major operational scenarios that later inform subsystem design, verification and validation.", "To provide input to planning for roles, responsibilities and training of operational personnel.", "To directly replace detailed test procedures and step-by-step verification scripts for the system." ] }, "de": { "title": "Einsatzkonzept (Concept of Operations, CONOPS)", "text": "Welchen Zweck hat ein Einsatzkonzept (Concept of Operations, CONOPS)?", "answers": [ "Zu beschreiben, wie das System in seinem operativen Kontext aus der Perspektive der Nutzer und anderer Stakeholder verwendet wird.", "Die wesentlichen Einsatzszenarien zu umreißen, die später den Subsystementwurf, die Verifizierung und die Validierung informieren.", "Eingaben für die Planung von Rollen, Verantwortlichkeiten und Schulung des Betriebspersonals bereitzustellen.", "Detaillierte Testprozeduren und schrittweise Verifizierungsskripte für das System unmittelbar zu ersetzen." ] } }, { "number": 43, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Requirements baseline", "text": "Establishing a requirements baseline means:", "answers": [ "Formally approving a controlled set of requirements to serve as the baseline for further development and change control.", "Ensuring that subsequent changes to requirements must follow a formal change control and impact analysis process.", "Typically aligning the approved requirements set with a major review milestone such as a System Requirements Review.", "Finalising the design even though requirements have not yet been fully agreed by the stakeholders." ] }, "de": { "title": "Anforderungs-Baseline", "text": "Das Festlegen einer Anforderungs-Baseline bedeutet:", "answers": [ "Eine kontrollierte Menge von Anforderungen formal zu genehmigen, die als Baseline für die weitere Entwicklung und Änderungssteuerung dient.", "Sicherzustellen, dass nachfolgende Änderungen an Anforderungen einem formalen Änderungssteuerungs- und Auswirkungsanalyseprozess folgen müssen.", "Die genehmigte Anforderungsmenge typischerweise auf einen wichtigen Review-Meilenstein wie ein System Requirements Review auszurichten.", "Den Entwurf abzuschließen, obwohl die Anforderungen von den Stakeholdern noch nicht vollständig vereinbart wurden." ] } }, { "number": 44, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Change control", "text": "Typical steps for changing a requirement are:", "answers": [ "Submitting a change request, analysing its impact, deciding whether to approve it, and then implementing and communicating the approved change.", "Coordinating requirement updates through informal team reviews when impacts appear limited or low risk.", "Archiving superseded requirements so that obsolete statements are not accidentally used in future work.", "Changing only the design documents while intentionally leaving the requirement set unchanged." ] }, "de": { "title": "Änderungssteuerung", "text": "Typische Schritte zur Änderung einer Anforderung sind:", "answers": [ "Einreichen eines Änderungsantrags, Analyse seiner Auswirkungen, Entscheidung über die Genehmigung sowie anschließende Umsetzung und Kommunikation der genehmigten Änderung.", "Koordinierung von Anforderungsaktualisierungen durch informelle Teamüberprüfungen, wenn die Auswirkungen begrenzt oder risikoarm erscheinen.", "Archivierung überholter Anforderungen, damit veraltete Aussagen nicht versehentlich in zukünftigen Arbeiten verwendet werden.", "Änderung ausschließlich der Entwurfsdokumente unter bewusster Beibehaltung des unveränderten Anforderungssatzes." ] } }, { "number": 45, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Requirements hierarchy", "text": "Typical hierarchy of requirements is:", "answers": [ "Mission needs, then stakeholder requirements, followed by system, subsystem and component requirements.", "In some bottom-up developments, detailed constraints at component level are discovered first and later influence system-level requirements.", "Many projects emphasise system-level requirements while deriving detailed allocations during design activities.", "Stakeholder needs, then test procedures, and finally system requirements defined from the tests." ] }, "de": { "title": "Anforderungshierarchie", "text": "Die typische Hierarchie von Anforderungen ist:", "answers": [ "Missionsbedürfnisse, dann Stakeholder-Anforderungen, gefolgt von System-, Subsystem- und Komponentenanforderungen.", "In einigen Bottom-up-Entwicklungen werden detaillierte Randbedingungen auf Komponentenebene zuerst entdeckt und beeinflussen später die Anforderungen auf Systemebene.", "Viele Projekte betonen die Anforderungen auf Systemebene und leiten detaillierte Zuweisungen während der Entwurfsaktivitäten ab.", "Stakeholder-Bedürfnisse, dann Testprozeduren und schließlich Systemanforderungen, die aus den Tests definiert werden." ] } }, { "number": 46, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "System-of-systems (SoS) requirements", "text": "In System of Systems engineering, SoS requirements:", "answers": [ "Are allocated to constituent systems and often drive updates or extensions to those systems’ own requirements.", "Often constrain how constituent systems are used and interfaced, even if their internal designs are not radically altered.", "May start from the existing capabilities of constituent systems and then refine additional needs at system-of-systems level.", "Apply exclusively to separate enabling systems that are not considered part of the system of systems." ] }, "de": { "title": "Anforderungen an ein System von Systemen (SoS)", "text": "Im Engineering von Systemen von Systemen gilt für SoS-Anforderungen:", "answers": [ "Sie werden den konstituierenden Systemen zugeordnet und treiben häufig Aktualisierungen oder Erweiterungen der eigenen Anforderungen dieser Systeme voran.", "Sie schränken oft ein, wie konstituierende Systeme genutzt und miteinander verbunden werden, auch wenn ihre internen Entwürfe nicht grundlegend verändert werden.", "Sie können von den vorhandenen Fähigkeiten der konstituierenden Systeme ausgehen und dann zusätzliche Bedürfnisse auf der Ebene des Systems von Systemen verfeinern.", "Sie gelten ausschließlich für separate unterstützende Systeme, die nicht als Teil des Systems von Systemen betrachtet werden." ] } }, { "number": 47, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288;INCOSE_SEH5", "en": { "title": "Architecture definition", "text": "Purpose of architecture definition process is:", "answers": [ "To create and evaluate architecture candidates and select an architecture that satisfies the requirements and constraints.", "To define the main structural choices and interfaces that will guide later detailed design and implementation.", "To provide inputs to planning, contracting and risk management by clarifying major system elements and their roles.", "To run day-to-day system operations according to the chosen configuration of components and subsystems." ] }, "de": { "title": "Architekturdefinition", "text": "Der Zweck des Architekturdefinitionsprozesses ist:", "answers": [ "Architekturkandidaten zu erstellen und zu bewerten und eine Architektur auszuwählen, die die Anforderungen und Randbedingungen erfüllt.", "Die wesentlichen strukturellen Entscheidungen und Schnittstellen zu definieren, die den späteren Detailentwurf und die Umsetzung leiten.", "Eingaben für Planung, Vertragsgestaltung und Risikomanagement bereitzustellen, indem wesentliche Systemelemente und ihre Rollen geklärt werden.", "Den täglichen Systembetrieb gemäß der gewählten Konfiguration von Komponenten und Teilsystemen durchzuführen." ] } }, { "number": 48, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Logical vs physical architecture", "text": "Which statements are correct?", "answers": [ "Logical architecture describes functions, behaviours and their relationships independently of implementation.", "Physical architecture describes physical elements and interfaces that realise the logical architecture.", "They are identical terms that refer to any description of system structure.", "Logical architecture applies only to software systems and not to hardware or socio-technical systems." ] }, "de": { "title": "Logische versus physische Architektur", "text": "Welche Aussagen sind korrekt?", "answers": [ "Die logische Architektur beschreibt Funktionen, Verhaltensweisen und deren Beziehungen unabhängig von der Implementierung.", "Die physische Architektur beschreibt physische Elemente und Schnittstellen, die die logische Architektur realisieren.", "Sie sind identische Begriffe, die sich auf jede Beschreibung der Systemstruktur beziehen.", "Die logische Architektur gilt nur für Softwaresysteme und nicht für Hardware oder soziotechnische Systeme." ] } }, { "number": 49, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "System analysis", "text": "Role of system analysis process is:", "answers": [ "To perform analyses and trade studies that support technical decision making throughout the life cycle.", "To produce quantitative insight into system behaviour that can feed into documentation and training materials.", "To provide data that may influence financial and contractual decisions by showing how alternatives perform.", "To approve and pay supplier invoices as part of the engineering analysis process." ] }, "de": { "title": "Systemanalyse", "text": "Die Rolle des Systemanalyseprozesses ist:", "answers": [ "Analysen und Trade-off-Analysen durchzuführen, die die technische Entscheidungsfindung über den gesamten Lebenszyklus hinweg unterstützen.", "Quantitative Erkenntnisse über das Systemverhalten zu erzeugen, die in Dokumentation und Schulungsunterlagen einfließen können.", "Daten bereitzustellen, die finanzielle und vertragliche Entscheidungen beeinflussen können, indem sie zeigen, wie Alternativen abschneiden.", "Lieferantenrechnungen als Teil des technischen Analyseprozesses zu genehmigen und zu bezahlen." ] } }, { "number": 50, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;NASA_SEH", "en": { "title": "Interface description artifacts", "text": "Which artifact typically captures interfaces?", "answers": [ "Interface Control Documents (ICDs) or equivalent interface descriptions.", "Risk registers that sometimes identify interfaces that are particularly critical or failure-prone.", "Organizational charts that clarify which teams own particular interfaces and are responsible for defining them.", "Maintenance manuals that describe only repair steps without defining design-time interfaces." ] }, "de": { "title": "Artefakte zur Schnittstellenbeschreibung", "text": "Welches Artefakt erfasst typischerweise Schnittstellen?", "answers": [ "Schnittstellenkontrolldokumente (Interface Control Documents, ICDs) oder gleichwertige Schnittstellenbeschreibungen.", "Risikoregister, die manchmal Schnittstellen identifizieren, die besonders kritisch oder ausfallanfällig sind.", "Organigramme, die verdeutlichen, welche Teams bestimmte Schnittstellen besitzen und für deren Definition verantwortlich sind.", "Wartungshandbücher, die nur Reparaturschritte beschreiben, ohne entwurfszeitliche Schnittstellen zu definieren." ] } }, { "number": 51, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Allocation in design", "text": "What does allocation mean in design?", "answers": [ "Assigning requirements and performance budgets to lower-level system elements and components.", "Distributing performance targets among subsystems based on engineering judgement as well as analysis.", "Relaxing some requirements at lower levels when agreed trade-offs show the original targets are not feasible.", "Reassigning managers or organizational units responsible for different parts of the project." ] }, "de": { "title": "Zuweisung im Entwurf", "text": "Was bedeutet Zuweisung (Allocation) im Entwurf?", "answers": [ "Zuordnung von Anforderungen und Leistungsbudgets zu Systemelementen und Komponenten niedrigerer Ebene.", "Verteilung von Leistungszielen auf Teilsysteme auf Basis von Ingenieururteil sowie Analyse.", "Lockerung einiger Anforderungen auf niedrigeren Ebenen, wenn vereinbarte Trade-offs zeigen, dass die ursprünglichen Ziele nicht realisierbar sind.", "Neuzuweisung von Managern oder Organisationseinheiten, die für verschiedene Teile des Projekts verantwortlich sind." ] } }, { "number": 52, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Design definition process", "text": "Design definition process includes:", "answers": [ "Developing detailed design descriptions that realise and implement the selected architecture.", "Refining high-level solution concepts into more detailed descriptions of components and interfaces.", "Specifying how components will be integrated and verified as part of the overall solution.", "Negotiating acceptance criteria with the acquirer without creating detailed design descriptions." ] }, "de": { "title": "Entwurfsdefinitionsprozess", "text": "Der Entwurfsdefinitionsprozess umfasst:", "answers": [ "Entwicklung detaillierter Entwurfsbeschreibungen, die die ausgewählte Architektur realisieren und implementieren.", "Verfeinerung übergeordneter Lösungskonzepte zu detaillierteren Beschreibungen von Komponenten und Schnittstellen.", "Festlegung, wie Komponenten als Teil der Gesamtlösung integriert und verifiziert werden.", "Verhandlung von Abnahmekriterien mit dem Erwerber, ohne detaillierte Entwurfsbeschreibungen zu erstellen." ] } }, { "number": 53, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK;INCOSE_SEH5", "en": { "title": "Model-based systems engineering (MBSE) basics", "text": "What is Model Based Systems Engineering (MBSE)?", "answers": [ "An approach in which formal system models are used as primary artifacts to support systems engineering activities.", "An evolution of document-based systems engineering where models are used more intensively alongside traditional specifications.", "A modelling approach that tends to be particularly valuable on software-intensive or highly complex systems.", "A method intended to eliminate the need for direct interaction with stakeholders by relying solely on automated models." ] }, "de": { "title": "Grundlagen des Model-Based Systems Engineering (MBSE)", "text": "Was ist Model-Based Systems Engineering (MBSE)?", "answers": [ "Ein Ansatz, bei dem formale Systemmodelle als primäre Artefakte zur Unterstützung von Systems-Engineering-Aktivitäten verwendet werden.", "Eine Weiterentwicklung des dokumentenbasierten Systems Engineering, bei der Modelle intensiver neben traditionellen Spezifikationen verwendet werden.", "Ein Modellierungsansatz, der bei softwareintensiven oder hochkomplexen Systemen tendenziell besonders wertvoll ist.", "Eine Methode, die die Notwendigkeit einer direkten Interaktion mit Stakeholdern beseitigen soll, indem sie sich ausschließlich auf automatisierte Modelle stützt." ] } }, { "number": 54, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "MBSE benefits", "text": "Which are typical MBSE benefits?", "answers": [ "Improved consistency, better traceability and increased potential for automation and model-based analysis.", "Earlier detection of many inconsistencies because models can often be checked automatically before documents are produced.", "Shared models can reduce duplication between documents, although configuration control of the models remains essential.", "Complete replacement of all communication and reviews by the model itself, making human discussion unnecessary." ] }, "de": { "title": "Vorteile von MBSE", "text": "Welches sind typische Vorteile von MBSE?", "answers": [ "Verbesserte Konsistenz, bessere Nachverfolgbarkeit und erhöhtes Potenzial für Automatisierung und modellbasierte Analysen.", "Frühere Erkennung vieler Inkonsistenzen, da Modelle oft automatisch geprüft werden können, bevor Dokumente erstellt werden.", "Gemeinsam genutzte Modelle können Doppelarbeit zwischen Dokumenten reduzieren, wobei die Konfigurationssteuerung der Modelle weiterhin unerlässlich bleibt.", "Vollständiger Ersatz jeglicher Kommunikation und Reviews durch das Modell selbst, wodurch menschliche Diskussion überflüssig wird." ] } }, { "number": 55, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Systems Modeling Language (SysML) role", "text": "What is SysML used for?", "answers": [ "A general-purpose modelling language used to specify, analyse, design and help verify systems.", "A notation that includes constructs for expressing software structure and behaviour within broader system models.", "A diagramming language whose timelines and dependency views can complement project schedules and planning.", "A file format used exclusively for creating 3D mechanical geometry models." ] }, "de": { "title": "Rolle der Systems Modeling Language (SysML)", "text": "Wofür wird SysML verwendet?", "answers": [ "Eine universelle Modellierungssprache zur Spezifikation, Analyse, zum Entwurf und zur Unterstützung der Verifizierung von Systemen.", "Eine Notation, die Konstrukte zum Ausdruck von Softwarestruktur und -verhalten innerhalb umfassenderer Systemmodelle enthält.", "Eine Diagrammsprache, deren Zeitachsen und Abhängigkeitsdarstellungen Projektterminpläne und -planung ergänzen können.", "Ein Dateiformat, das ausschließlich zur Erstellung von 3D-Maschinenbaugeometriemodellen verwendet wird." ] } }, { "number": 56, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_42010", "en": { "title": "Views and viewpoints (architecture descriptions)", "text": "According to ISO 42010, how do views and viewpoints relate?", "answers": [ "A viewpoint defines the conventions for constructing one or more views that address particular stakeholder concerns.", "Both help organise architectural descriptions, and in small projects the distinction is sometimes blurred in practice.", "In many tools, a view is represented as one or more diagrams created according to a chosen viewpoint.", "Formal views are discouraged because they add unnecessary structure to architectural descriptions." ] }, "de": { "title": "Sichten und Sichtweisen (Architekturbeschreibungen)", "text": "Wie stehen Sichten und Sichtweisen gemäß ISO 42010 in Beziehung?", "answers": [ "Eine Sichtweise definiert die Konventionen für die Konstruktion einer oder mehrerer Sichten, die bestimmte Stakeholder-Anliegen adressieren.", "Beide helfen, Architekturbeschreibungen zu organisieren, und in kleinen Projekten wird die Unterscheidung in der Praxis manchmal verwischt.", "In vielen Werkzeugen wird eine Sicht als ein oder mehrere Diagramme dargestellt, die gemäß einer gewählten Sichtweise erstellt werden.", "Von formalen Sichten wird abgeraten, da sie Architekturbeschreibungen unnötige Struktur hinzufügen." ] } }, { "number": 57, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Implementation process", "text": "What is the implementation process?", "answers": [ "Realising system elements by producing, fabricating or coding them in accordance with the design definition.", "Translating design information into detailed work instructions, build definitions or source code for implementation teams.", "Preparing the system so that it can later be operated safely, including some configuration of operational parameters.", "Focusing only on removing or scrapping system elements that are no longer required." ] }, "de": { "title": "Implementierungsprozess", "text": "Was ist der Implementierungsprozess?", "answers": [ "Die Realisierung von Systemelementen durch deren Herstellung, Fertigung oder Codierung in Übereinstimmung mit der Entwurfsdefinition.", "Die Übersetzung von Entwurfsinformationen in detaillierte Arbeitsanweisungen, Fertigungsdefinitionen oder Quellcode für die Implementierungsteams.", "Die Vorbereitung des Systems, sodass es später sicher betrieben werden kann, einschließlich einer gewissen Konfiguration von Betriebsparametern.", "Die ausschließliche Konzentration auf die Entfernung oder Verschrottung von Systemelementen, die nicht mehr benötigt werden." ] } }, { "number": 58, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Integration process", "text": "What is the integration process?", "answers": [ "Combining system elements into higher-level assemblies and verifying that their interactions and interfaces work as intended.", "Combining system elements into higher-level assemblies according to planned sequences that minimise integration risk.", "Coordinating facilities, tools and resources needed to assemble and check interacting system elements.", "Running normal operations of the fully integrated system without performing verification of the integrated configuration." ] }, "de": { "title": "Integrationsprozess", "text": "Was ist der Integrationsprozess?", "answers": [ "Das Zusammenfügen von Systemelementen zu übergeordneten Baugruppen und die Verifizierung, dass ihre Wechselwirkungen und Schnittstellen wie beabsichtigt funktionieren.", "Das Zusammenfügen von Systemelementen zu übergeordneten Baugruppen gemäß geplanten Abläufen, die das Integrationsrisiko minimieren.", "Das Koordinieren von Einrichtungen, Werkzeugen und Ressourcen, die zum Zusammenfügen und Prüfen wechselwirkender Systemelemente benötigt werden.", "Das Durchführen des Normalbetriebs des vollständig integrierten Systems, ohne eine Verifizierung der integrierten Konfiguration vorzunehmen." ] } }, { "number": 59, "correct": [ 0 ], "confidence": "HIGH", "sources": "NASA_SEH", "en": { "title": "Verification planning artifact", "text": "Which artifact links each requirement to one or more verification methods?", "answers": [ "A requirements verification matrix or verification cross-reference matrix.", "A work breakdown structure that may list verification tasks and milestones but does not map each requirement to methods.", "An organizational chart showing which teams are responsible for particular verification activities but not individual requirements.", "A risk log that records issues and concerns but does not link requirements to verification approaches." ] }, "de": { "title": "Artefakt der Verifizierungsplanung", "text": "Welches Artefakt verknüpft jede Anforderung mit einer oder mehreren Verifizierungsmethoden?", "answers": [ "Eine Anforderungs-Verifizierungsmatrix oder Verifizierungs-Querverweismatrix.", "Ein Projektstrukturplan, der Verifizierungsaufgaben und Meilensteine auflisten kann, aber nicht jede Anforderung auf Methoden abbildet.", "Ein Organigramm, das zeigt, welche Teams für bestimmte Verifizierungsaktivitäten verantwortlich sind, aber nicht für einzelne Anforderungen.", "Ein Risikoregister, das Probleme und Bedenken erfasst, aber Anforderungen nicht mit Verifizierungsansätzen verknüpft." ] } }, { "number": 60, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Validation activities", "text": "Which are typical validation activities?", "answers": [ "Activities such as exercising realistic operational scenarios with users using the system or high-fidelity simulations.", "Reviewing key test results with users to confirm that implemented functions support intended operations.", "Checking that procedures and manuals match how the system is actually used in realistic scenarios.", "Archiving outdated records at the end of the project instead of engaging users in realistic trials." ] }, "de": { "title": "Validierungsaktivitäten", "text": "Welche sind typische Validierungsaktivitäten?", "answers": [ "Aktivitäten wie das Durchspielen realistischer operativer Szenarien mit Nutzern, die das System oder hochgetreue Simulationen verwenden.", "Überprüfung wesentlicher Testergebnisse mit Nutzern, um zu bestätigen, dass die implementierten Funktionen die beabsichtigten Betriebsabläufe unterstützen.", "Prüfung, ob Verfahren und Handbücher der tatsächlichen Verwendung des Systems in realistischen Szenarien entsprechen.", "Archivierung veralteter Aufzeichnungen am Ende des Projekts, anstatt Nutzer in realistische Erprobungen einzubeziehen." ] } }, { "number": 61, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Transition process", "text": "What is the transition process?", "answers": [ "Transferring the system to the user or operator and enabling its use in the intended operational environment.", "Managing the handover from development teams to operations, including initial training and data migration.", "Coordinating acceptance tests and readiness reviews before the system enters full operation.", "Managing the organization’s entire portfolio of projects and investments across multiple systems." ] }, "de": { "title": "Übergangsprozess (Transition)", "text": "Was ist der Übergangsprozess (Transition)?", "answers": [ "Die Überführung des Systems an den Nutzer oder Betreiber und die Ermöglichung seiner Nutzung in der vorgesehenen Einsatzumgebung.", "Die Steuerung der Übergabe von den Entwicklungsteams an den Betrieb, einschließlich Erstschulung und Datenmigration.", "Die Koordination von Abnahmetests und Bereitschafts-Reviews, bevor das System in den vollen Betrieb übergeht.", "Die Verwaltung des gesamten Portfolios an Projekten und Investitionen der Organisation über mehrere Systeme hinweg." ] } }, { "number": 62, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Operation process", "text": "Responsibilities in the operation process include:", "answers": [ "Operating the system according to defined procedures to deliver the required services to stakeholders.", "Executing routine procedures and monitoring performance to keep services within agreed levels.", "Coordinating operators and support staff so that the system can be run according to the operational plan.", "Closing and dismantling facilities once the system is no longer needed for its intended mission." ] }, "de": { "title": "Betriebsprozess", "text": "Zu den Verantwortlichkeiten im Betriebsprozess gehören:", "answers": [ "Das Betreiben des Systems gemäß definierten Verfahren, um den Stakeholdern die geforderten Dienste zu liefern.", "Das Ausführen routinemäßiger Verfahren und das Überwachen der Leistung, um die Dienste innerhalb vereinbarter Niveaus zu halten.", "Das Koordinieren von Bedienpersonal und Unterstützungspersonal, sodass das System gemäß dem Betriebsplan betrieben werden kann.", "Das Schließen und Rückbauen von Einrichtungen, sobald das System für seine vorgesehene Mission nicht mehr benötigt wird." ] } }, { "number": 63, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Maintenance process", "text": "Which are typical maintenance activities?", "answers": [ "Diagnosing faults and repairing or replacing failed components to restore system performance.", "Assessing operational data to plan upgrades and modifications that improve reliability and supportability.", "Planning and scheduling preventive and corrective work to keep the system in acceptable condition.", "Destroying hazardous materials only after the system has been fully retired from service." ] }, "de": { "title": "Instandhaltungsprozess", "text": "Welche sind typische Instandhaltungsaktivitäten?", "answers": [ "Fehler diagnostizieren und ausgefallene Komponenten reparieren oder ersetzen, um die Systemleistung wiederherzustellen.", "Betriebsdaten auswerten, um Upgrades und Modifikationen zu planen, die Zuverlässigkeit und Unterstützbarkeit verbessern.", "Planung und Terminierung präventiver und korrektiver Arbeiten, um das System in einem akzeptablen Zustand zu halten.", "Gefahrstoffe erst dann vernichten, nachdem das System vollständig aus dem Betrieb genommen wurde." ] } }, { "number": 64, "correct": [ 0, 1, 2 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Maintenance strategies", "text": "Which maintenance strategies are common?", "answers": [ "Corrective (repair after failure).", "Preventive (scheduled before failure).", "Predictive or condition-based maintenance.", "Ignoring maintenance and replacing the entire system only when it can no longer operate at all." ] }, "de": { "title": "Wartungsstrategien", "text": "Welche Wartungsstrategien sind üblich?", "answers": [ "Korrektiv (Reparatur nach Ausfall).", "Präventiv (planmäßig vor Ausfall).", "Prädiktive oder zustandsbasierte Wartung.", "Wartung ignorieren und das gesamte System erst dann ersetzen, wenn es überhaupt nicht mehr betrieben werden kann." ] } }, { "number": 65, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Disposal", "text": "Which statements about disposal are correct?", "answers": [ "Disposal includes planning for safe removal, recycling or destruction of system elements.", "Environmental and regulatory constraints must be considered when planning and executing disposal.", "Disposal is unnecessary for software systems because they have no physical components.", "Disposal activities are always unplanned and carried out on an ad hoc basis at the end of life." ] }, "de": { "title": "Entsorgung", "text": "Welche Aussagen über die Entsorgung sind korrekt?", "answers": [ "Die Entsorgung umfasst die Planung für die sichere Entfernung, das Recycling oder die Zerstörung von Systemelementen.", "Bei der Planung und Durchführung der Entsorgung müssen umweltbezogene und regulatorische Randbedingungen berücksichtigt werden.", "Die Entsorgung ist für Softwaresysteme unnötig, da sie keine physischen Komponenten besitzen.", "Entsorgungsaktivitäten sind stets ungeplant und werden am Ende der Lebensdauer ad hoc durchgeführt." ] } }, { "number": 66, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK;INCOSE_SEH5", "en": { "title": "Feedback from operations", "text": "Why collect feedback from operations?", "answers": [ "To update models and requirements, improve future systems and refine maintenance strategies based on operational experience.", "To provide evidence for audits and demonstrate that operations are being monitored and documented.", "To identify improvement opportunities that may influence future design and maintenance decisions.", "To replace verification and validation activities or to ignore system quality attributes." ] }, "de": { "title": "Rückmeldungen aus dem Betrieb", "text": "Warum sollten Rückmeldungen aus dem Betrieb erhoben werden?", "answers": [ "Um Modelle und Anforderungen zu aktualisieren, künftige Systeme zu verbessern und Wartungsstrategien auf Basis der Betriebserfahrung zu verfeinern.", "Um Nachweise für Audits bereitzustellen und zu belegen, dass der Betrieb überwacht und dokumentiert wird.", "Um Verbesserungsmöglichkeiten zu identifizieren, die künftige Entwurfs- und Wartungsentscheidungen beeinflussen können.", "Um Verifizierungs- und Validierungstätigkeiten zu ersetzen oder Qualitätsattribute des Systems zu ignorieren." ] } }, { "number": 67, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK_RAM", "en": { "title": "Reliability", "text": "What is system reliability?", "answers": [ "The probability that a system performs its intended function for a specified period under stated conditions.", "A property related to how often failures occur, but not by itself capturing repair times or downtime.", "Over an observation period, a factor that strongly influences the fraction of time the system can perform its function.", "The system’s ability to resist malicious cyber attacks regardless of its failure behaviour." ] }, "de": { "title": "Zuverlässigkeit", "text": "Was ist Systemzuverlässigkeit?", "answers": [ "Die Wahrscheinlichkeit, dass ein System seine vorgesehene Funktion für einen bestimmten Zeitraum unter festgelegten Bedingungen erfüllt.", "Eine Eigenschaft, die damit zusammenhängt, wie häufig Ausfälle auftreten, die aber für sich genommen Reparaturzeiten oder Ausfallzeiten nicht erfasst.", "Über einen Beobachtungszeitraum ein Faktor, der den Anteil der Zeit, in der das System seine Funktion erfüllen kann, stark beeinflusst.", "Die Fähigkeit des Systems, böswilligen Cyberangriffen zu widerstehen, unabhängig von seinem Ausfallverhalten." ] } }, { "number": 68, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK_RAM", "en": { "title": "Availability", "text": "What is availability?", "answers": [ "The ability of a system to be in a functioning state when required, taking into account both failures and repair times.", "A measure influenced by both failure frequency and how quickly repairs can be completed.", "A property that can often be improved by combining reliability, maintainability and redundancy techniques.", "The capability to withstand cyber or physical attacks irrespective of system uptime." ] }, "de": { "title": "Verfügbarkeit", "text": "Was ist Verfügbarkeit?", "answers": [ "Die Fähigkeit eines Systems, sich bei Bedarf in einem funktionsfähigen Zustand zu befinden, wobei sowohl Ausfälle als auch Reparaturzeiten berücksichtigt werden.", "Ein Maß, das sowohl von der Ausfallhäufigkeit als auch davon beeinflusst wird, wie schnell Reparaturen abgeschlossen werden können.", "Eine Eigenschaft, die häufig durch die Kombination von Zuverlässigkeit, Wartbarkeit und Redundanztechniken verbessert werden kann.", "Die Fähigkeit, Cyber- oder physischen Angriffen standzuhalten, unabhängig von der Systembetriebszeit." ] } }, { "number": 69, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK_RAM", "en": { "title": "Maintainability", "text": "What is maintainability?", "answers": [ "The probability that a system can be restored to a required condition within a specified time using stated resources and procedures.", "A design property that aims to reduce downtime by simplifying diagnosis and repair activities.", "An attribute that strongly influences maintenance concepts, tools and skills needed in service.", "The ability of the system to exchange information seamlessly with other systems, regardless of ease of repair." ] }, "de": { "title": "Wartbarkeit", "text": "Was ist Wartbarkeit?", "answers": [ "Die Wahrscheinlichkeit, dass ein System innerhalb einer festgelegten Zeit unter Verwendung angegebener Ressourcen und Verfahren in einen geforderten Zustand zurückversetzt werden kann.", "Eine Entwurfseigenschaft, die darauf abzielt, Ausfallzeiten durch Vereinfachung von Diagnose- und Reparaturaktivitäten zu reduzieren.", "Ein Attribut, das die im Einsatz benötigten Wartungskonzepte, Werkzeuge und Fähigkeiten stark beeinflusst.", "Die Fähigkeit des Systems, unabhängig von der Reparaturfreundlichkeit nahtlos Informationen mit anderen Systemen auszutauschen." ] } }, { "number": 70, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "System safety vs system security", "text": "Which statements are correct?", "answers": [ "System safety focuses on preventing unintentional harm from hazards and failures.", "System security focuses on protection against intentional or unintentional adverse actions.", "They are completely independent and never interact in real systems.", "Only safety is considered a quality attribute in systems engineering." ] }, "de": { "title": "Systemsicherheit (Safety) versus Systemsicherheit (Security)", "text": "Welche Aussagen sind korrekt?", "answers": [ "Die Systemsicherheit (Safety) konzentriert sich auf die Vermeidung unbeabsichtigter Schäden durch Gefährdungen und Ausfälle.", "Die Systemsicherheit (Security) konzentriert sich auf den Schutz gegen absichtliche oder unbeabsichtigte nachteilige Handlungen.", "Sie sind vollständig voneinander unabhängig und interagieren in realen Systemen niemals.", "Nur die Sicherheit (Safety) wird im Systems Engineering als Qualitätsattribut betrachtet." ] } }, { "number": 71, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Interoperability", "text": "What is interoperability?", "answers": [ "The ability of systems to exchange information and to make effective use of the information exchanged.", "The capability to exchange data with minimal need for manual translation or reformatting between systems.", "Coordination of shared processes so that the information exchanged produces useful joint outcomes.", "Only the ability of a single system to run faster regardless of its connections to other systems." ] }, "de": { "title": "Interoperabilität", "text": "Was ist Interoperabilität?", "answers": [ "Die Fähigkeit von Systemen, Informationen auszutauschen und die ausgetauschten Informationen wirksam zu nutzen.", "Die Fähigkeit, Daten mit minimalem Bedarf an manueller Übersetzung oder Neuformatierung zwischen Systemen auszutauschen.", "Koordination gemeinsamer Prozesse, sodass die ausgetauschten Informationen nützliche gemeinsame Ergebnisse erzeugen.", "Lediglich die Fähigkeit eines einzelnen Systems, schneller zu laufen, unabhängig von seinen Verbindungen zu anderen Systemen." ] } }, { "number": 72, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "Resilience in systems engineering", "text": "What is resilience in systems engineering?", "answers": [ "The ability to maintain required capability in the face of adversity by withstanding disruptions and recovering from them.", "Designing systems so that failures are rare while still providing recovery mechanisms for important functions.", "Balancing performance with the ability to continue operating acceptably under a range of disruption scenarios.", "A characteristic that applies only to the systems engineering process, not to the delivered system itself." ] }, "de": { "title": "Resilienz im Systems Engineering", "text": "Was ist Resilienz im Systems Engineering?", "answers": [ "Die Fähigkeit, die geforderte Leistungsfähigkeit angesichts von Widrigkeiten aufrechtzuerhalten, indem Störungen standgehalten und von ihnen erholt wird.", "Systeme so zu entwerfen, dass Ausfälle selten sind, während gleichzeitig Wiederherstellungsmechanismen für wichtige Funktionen bereitgestellt werden.", "Ausgleich zwischen Leistung und der Fähigkeit, unter einer Reihe von Störungsszenarien akzeptabel weiterzuarbeiten.", "Eine Eigenschaft, die nur für den Systems-Engineering-Prozess gilt, nicht für das gelieferte System selbst." ] } }, { "number": 73, "correct": [ 0, 1 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Usability and human-systems integration (HSI)", "text": "Which statements about human system integration are correct?", "answers": [ "Operators, maintainers and users are considered system elements in systems engineering.", "Good human factors design can reduce errors and improve safety and performance.", "Human interaction is outside the scope of systems engineering and is left entirely to operations.", "Usability is irrelevant if the hardware is sufficiently reliable and available." ] }, "de": { "title": "Gebrauchstauglichkeit und Human-Systems Integration (HSI)", "text": "Welche Aussagen über die Human-Systems Integration sind korrekt?", "answers": [ "Bediener, Instandhalter und Nutzer werden im Systems Engineering als Systemelemente betrachtet.", "Ein guter Human-Factors-Entwurf kann Fehler reduzieren und Sicherheit sowie Leistung verbessern.", "Die menschliche Interaktion liegt außerhalb des Umfangs des Systems Engineering und wird vollständig dem Betrieb überlassen.", "Die Gebrauchstauglichkeit ist irrelevant, wenn die Hardware ausreichend zuverlässig und verfügbar ist." ] } }, { "number": 74, "correct": [ 0 ], "confidence": "GOOD", "sources": "SEBoK", "en": { "title": "Environmental impact", "text": "How is environmental impact handled?", "answers": [ "As a life cycle concern, with requirements and analyses covering emissions, waste and use of resources.", "It is especially scrutinised during disposal and decommissioning, where waste management is critical.", "Its importance varies by domain; in some missions, such as space, certain environmental concerns are more heavily regulated.", "It is left completely to external regulators, with no internal engineering responsibility for environmental aspects." ] }, "de": { "title": "Umweltauswirkungen", "text": "Wie werden Umweltauswirkungen behandelt?", "answers": [ "Als ein Lebenszyklusbelang, wobei Anforderungen und Analysen Emissionen, Abfälle und Ressourcenverbrauch abdecken.", "Sie werden besonders während der Entsorgung und Außerbetriebnahme geprüft, wo die Abfallbewirtschaftung entscheidend ist.", "Ihre Bedeutung variiert je nach Anwendungsbereich; in manchen Missionen, etwa im Weltraum, sind bestimmte Umweltbelange stärker reguliert.", "Sie werden vollständig externen Regulierungsbehörden überlassen, ohne interne ingenieurtechnische Verantwortung für Umweltaspekte." ] } }, { "number": 75, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Performance vs affordability", "text": "Systems engineering perspective on performance vs affordability is:", "answers": [ "To seek balanced solutions that meet performance and quality needs within acceptable cost, schedule and risk constraints.", "For high-priority missions, performance may be given more weight, but cost and schedule constraints must still be respected.", "Cost and schedule are sometimes prioritised, but performance shortfalls can jeopardise mission success and must be managed explicitly.", "Affordability is considered only after the system is in full operation and no longer influences design decisions." ] }, "de": { "title": "Leistung vs. Erschwinglichkeit", "text": "Die Sichtweise des Systems Engineering auf Leistung vs. Erschwinglichkeit ist:", "answers": [ "Ausgewogene Lösungen anzustreben, die Leistungs- und Qualitätsbedürfnisse innerhalb akzeptabler Kosten-, Termin- und Risikorandbedingungen erfüllen.", "Bei Missionen hoher Priorität kann der Leistung mehr Gewicht beigemessen werden, aber Kosten- und Terminrandbedingungen müssen dennoch eingehalten werden.", "Kosten und Termine werden mitunter priorisiert, aber Leistungsdefizite können den Missionserfolg gefährden und müssen ausdrücklich gesteuert werden.", "Erschwinglichkeit wird erst betrachtet, nachdem das System im vollen Betrieb ist, und beeinflusst Entwurfsentscheidungen nicht mehr." ] } }, { "number": 76, "correct": [ 0, 1, 2 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "System-of-systems (SoS) characteristics", "text": "Which characteristics are typical of systems of systems?", "answers": [ "Operational independence of constituent systems.", "Managerial independence of constituent systems.", "Evolutionary development and emergent behaviour at the SoS level.", "Tight centralised control of all constituents and the absence of emergent behaviour." ] }, "de": { "title": "Merkmale eines Systems von Systemen (SoS)", "text": "Welche Merkmale sind typisch für Systeme von Systemen?", "answers": [ "Operative Unabhängigkeit der Bestandteilsysteme.", "Managementbezogene Unabhängigkeit der Bestandteilsysteme.", "Evolutionäre Entwicklung und emergentes Verhalten auf der SoS-Ebene.", "Enge zentralisierte Steuerung aller Bestandteile und das Fehlen von emergentem Verhalten." ] } }, { "number": 77, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "System-of-systems (SoS) types", "text": "Which are common SoS types (Maier taxonomy)?", "answers": [ "Directed, acknowledged, collaborative and virtual systems of systems.", "Waterfall, spiral, incremental and agile development approaches that can be applied to systems of systems.", "Functional, physical, logical and behavioural viewpoints used when describing complex systems.", "Categories based solely on whether elements are hardware, software, human or organizational systems." ] }, "de": { "title": "System-von-Systemen-(SoS-)Typen", "text": "Welche sind gängige SoS-Typen (Maier-Taxonomie)?", "answers": [ "Gerichtete (directed), anerkannte (acknowledged), kollaborative (collaborative) und virtuelle (virtual) Systeme von Systemen.", "Wasserfall-, Spiral-, inkrementelle und agile Entwicklungsansätze, die auf Systeme von Systemen angewendet werden können.", "Funktionale, physische, logische und verhaltensbezogene Sichtweisen, die bei der Beschreibung komplexer Systeme verwendet werden.", "Kategorien, die ausschließlich darauf beruhen, ob die Elemente Hardware-, Software-, menschliche oder organisatorische Systeme sind." ] } }, { "number": 78, "correct": [ 0, 1, 2 ], "confidence": "HIGH", "sources": "SEBoK", "en": { "title": "System-of-systems (SoS) challenges", "text": "Typical challenges of SoS engineering include:", "answers": [ "Independent evolution of constituent systems outside the direct control of the SoS authority.", "Difficulty of achieving comprehensive end-to-end testing across all constituent systems and scenarios.", "Emergent behaviour at the SoS level that is not directly predictable from individual system behaviours.", "Guaranteed centralised control of all changes and strict configuration control across all constituents." ] }, "de": { "title": "Herausforderungen bei Systemen von Systemen (SoS)", "text": "Zu den typischen Herausforderungen des SoS-Engineerings gehören:", "answers": [ "Die unabhängige Weiterentwicklung konstituierender Systeme außerhalb der direkten Kontrolle der SoS-Instanz.", "Die Schwierigkeit, ein umfassendes durchgängiges Testen über alle konstituierenden Systeme und Szenarien hinweg zu erreichen.", "Emergentes Verhalten auf der SoS-Ebene, das nicht direkt aus dem Verhalten der einzelnen Systeme vorhersehbar ist.", "Garantierte zentralisierte Steuerung aller Änderungen und strikte Konfigurationssteuerung über alle konstituierenden Systeme hinweg." ] } }, { "number": 79, "correct": [ 0 ], "confidence": "GOOD", "sources": "SEBoK", "en": { "title": "Systems engineering (SE) role in system-of-systems (SoS) context", "text": "Role of systems engineer in SoS context is:", "answers": [ "To coordinate, negotiate and align independently managed systems so that overall system-of-systems objectives are met.", "To balance the needs of different stakeholder groups, particularly those owning key constituent systems.", "To facilitate technical integration discussions while overarching governance is handled by programme management.", "To deliberately avoid using configuration or risk management so that changes can be made informally when needed." ] }, "de": { "title": "Rolle des Systems Engineering (SE) im Kontext von System von Systemen (SoS)", "text": "Die Rolle des Systemingenieurs im SoS-Kontext ist:", "answers": [ "Unabhängig verwaltete Systeme zu koordinieren, zu verhandeln und aufeinander abzustimmen, sodass die übergreifenden Ziele des Systems von Systemen erreicht werden.", "Die Bedürfnisse verschiedener Stakeholder-Gruppen auszubalancieren, insbesondere derjenigen, die zentrale konstituierende Systeme besitzen.", "Technische Integrationsdiskussionen zu moderieren, während die übergreifende Governance durch das Programmmanagement gehandhabt wird.", "Bewusst auf Konfigurations- oder Risikomanagement zu verzichten, damit Änderungen bei Bedarf informell vorgenommen werden können." ] } }, { "number": 80, "correct": [ 0 ], "confidence": "HIGH", "sources": "NASA_SEH", "en": { "title": "National Aeronautics and Space Administration (NASA) life cycle – formulation phases", "text": "In NASA life cycle, which phases are formulation?", "answers": [ "Phases A and B in the NASA life cycle.", "Phases C and D, which address detailed design, development and integration of the system.", "Phases E and F, which primarily cover operations and mission closeout.", "NASA projects are managed without any formal definition of life cycle phases." ] }, "de": { "title": "Lebenszyklus der National Aeronautics and Space Administration (NASA) – Formulierungsphasen", "text": "Welche Phasen sind im NASA-Lebenszyklus die Formulierungsphasen?", "answers": [ "Die Phasen A und B im NASA-Lebenszyklus.", "Die Phasen C und D, die den detaillierten Entwurf, die Entwicklung und die Integration des Systems behandeln.", "Die Phasen E und F, die hauptsächlich den Betrieb und den Missionsabschluss abdecken.", "NASA-Projekte werden ohne jegliche formale Definition von Lebenszyklusphasen gesteuert." ] } }, { "number": 81, "correct": [ 0 ], "confidence": "HIGH", "sources": "NASA_SEH", "en": { "title": "National Aeronautics and Space Administration (NASA) life cycle – implementation phases", "text": "In NASA life cycle, which phases are primarily implementation (system realization)?", "answers": [ "Phases C and D in the NASA life cycle.", "Phases A and B, which focus on pre-Phase C formulation including feasibility and initial design.", "Phases E and F, which primarily cover operations and decommissioning activities.", "A single undifferentiated phase that covers concept, design, implementation and operations." ] }, "de": { "title": "Lebenszyklus der National Aeronautics and Space Administration (NASA) – Implementierungsphasen", "text": "Welche Phasen sind im NASA-Lebenszyklus vorrangig Implementierung (Systemrealisierung)?", "answers": [ "Die Phasen C und D im NASA-Lebenszyklus.", "Die Phasen A und B, die sich auf die Formulierung vor Phase C konzentrieren, einschließlich Machbarkeit und ersten Entwurf.", "Die Phasen E und F, die vorrangig Betriebs- und Außerbetriebnahmeaktivitäten abdecken.", "Eine einzige undifferenzierte Phase, die Konzept, Entwurf, Implementierung und Betrieb umfasst." ] } }, { "number": 82, "correct": [ 0 ], "confidence": "HIGH", "sources": "NASA_SEH", "en": { "title": "National Aeronautics and Space Administration (NASA) systems engineering (SE) engine", "text": "What is the NASA systems engineering engine?", "answers": [ "A depiction of recurring systems engineering processes that are applied iteratively across project phases.", "A NASA diagram that emphasises recurring technical processes throughout the project life cycle.", "A NASA-specific systems engineering framework that tailors process groupings to space missions while remaining conceptually compatible with ISO 15288.", "A particular rocket engine that physically embodies NASA’s systems engineering principles." ] }, "de": { "title": "Systems-Engineering-(SE-)Engine der National Aeronautics and Space Administration (NASA)", "text": "Was ist die Systems-Engineering-Engine der NASA?", "answers": [ "Eine Darstellung wiederkehrender Systems-Engineering-Prozesse, die iterativ über die Projektphasen hinweg angewendet werden.", "Ein NASA-Diagramm, das wiederkehrende technische Prozesse über den gesamten Projektlebenszyklus hinweg hervorhebt.", "Ein NASA-spezifisches Systems-Engineering-Rahmenwerk, das Prozessgruppierungen auf Weltraummissionen zuschneidet, dabei aber konzeptionell mit ISO 15288 kompatibel bleibt.", "Ein bestimmtes Raketentriebwerk, das die Systems-Engineering-Prinzipien der NASA physisch verkörpert." ] } }, { "number": 83, "correct": [ 0 ], "confidence": "HIGH", "sources": "ECSS_E_ST_10", "en": { "title": "European Cooperation for Space Standardization (ECSS) engineering series", "text": "In a space project that follows ECSS standards, what is the primary focus of the ECSS-E series?", "answers": [ "It defines engineering and systems engineering requirements that complement ECSS management (M) and product assurance (Q) standards for space projects.", "It mainly describes high-level project management processes, with only limited reference to engineering activities.", "It specifies product assurance and quality rules that apply to hardware and software in space missions.", "It provides financial accounting and budgeting guidance for national and international space agencies." ] }, "de": { "title": "Engineering-Reihe der European Cooperation for Space Standardization (ECSS)", "text": "Was ist in einem Raumfahrtprojekt, das ECSS-Standards befolgt, der primäre Fokus der ECSS-E-Reihe?", "answers": [ "Sie definiert Engineering- und Systems-Engineering-Anforderungen, die die ECSS-Management- (M) und Produktsicherungsstandards (Q) für Raumfahrtprojekte ergänzen.", "Sie beschreibt hauptsächlich übergeordnete Projektmanagementprozesse mit nur begrenztem Bezug zu Engineering-Aktivitäten.", "Sie legt Produktsicherungs- und Qualitätsregeln fest, die für Hardware und Software in Raumfahrtmissionen gelten.", "Sie liefert Anleitungen zur Finanzbuchhaltung und Budgetierung für nationale und internationale Raumfahrtagenturen." ] } }, { "number": 84, "correct": [ 0 ], "confidence": "HIGH", "sources": "ECSS_E_ST_10", "en": { "title": "European Cooperation for Space Standardization (ECSS) systems engineering general requirements", "text": "How is ECSS-E-ST-10 used in the context of a space project that applies ECSS standards?", "answers": [ "It sets out general systems engineering requirements that projects tailor and flow down across all life cycle phases.", "It is treated as the primary ECSS engineering reference and some teams attempt to rely on it without extensive use of other ECSS engineering standards.", "It includes systems engineering provisions but is often interpreted as focusing mainly on technical design aspects rather than the entire system life cycle.", "It is used mainly to define project roles and responsibilities for engineering staff, rather than specifying technical requirements for the system." ] }, "de": { "title": "Allgemeine Systems-Engineering-Anforderungen der European Cooperation for Space Standardization (ECSS)", "text": "Wie wird ECSS-E-ST-10 im Kontext eines Raumfahrtprojekts verwendet, das ECSS-Standards anwendet?", "answers": [ "Sie legt allgemeine Systems-Engineering-Anforderungen fest, die Projekte über alle Lebenszyklusphasen hinweg zuschneiden und weiterreichen.", "Sie wird als die primäre technische ECSS-Referenz behandelt, und einige Teams versuchen, sich ohne umfassende Verwendung anderer technischer ECSS-Standards auf sie zu stützen.", "Sie enthält Systems-Engineering-Bestimmungen, wird aber oft so interpretiert, dass sie sich hauptsächlich auf technische Entwurfsaspekte konzentriert und nicht auf den gesamten Systemlebenszyklus.", "Sie wird hauptsächlich verwendet, um Projektrollen und -verantwortlichkeiten für das Ingenieurpersonal zu definieren, statt technische Anforderungen an das System festzulegen." ] } }, { "number": 85, "correct": [ 0 ], "confidence": "GOOD", "sources": "SEBoK", "en": { "title": "Digital engineering and model-based systems engineering (MBSE)", "text": "How does MBSE relate to digital engineering?", "answers": [ "MBSE is often viewed as a subset of digital engineering that focuses on system models within the broader digital thread.", "Digital engineering is frequently associated with CAD, simulation and model repositories that MBSE models can feed.", "Digital engineering focuses on integrating data and tools, while requirements and verification and validation are still essential parts of the digital thread.", "Digital engineering refers solely to software coding practices on digital platforms and does not involve systems engineering." ] }, "de": { "title": "Digital Engineering und Model-Based Systems Engineering (MBSE)", "text": "In welcher Beziehung steht MBSE zum Digital Engineering?", "answers": [ "MBSE wird häufig als Teilmenge des Digital Engineering betrachtet, die sich auf Systemmodelle innerhalb des umfassenderen Digital Thread konzentriert.", "Digital Engineering wird häufig mit CAD, Simulation und Modell-Repositories in Verbindung gebracht, in die MBSE-Modelle einfließen können.", "Digital Engineering konzentriert sich auf die Integration von Daten und Werkzeugen, während Anforderungen sowie Verifizierung und Validierung nach wie vor wesentliche Bestandteile des Digital Thread sind.", "Digital Engineering bezieht sich ausschließlich auf Softwarecodierungspraktiken auf digitalen Plattformen und beinhaltet kein Systems Engineering." ] } }, { "number": 86, "correct": [ 0, 1 ], "confidence": "GOOD", "sources": "SEBoK", "en": { "title": "Simulation in model-based systems engineering (MBSE)", "text": "Which statements about simulation in MBSE are correct?", "answers": [ "Simulations can be driven by system models to evaluate behavior and performance under various scenarios.", "Simulation results can contribute to verification and validation evidence when properly planned and documented.", "Simulation completely replaces physical testing in all cases, making prototypes unnecessary.", "Simulation is relevant only after deployment, when the system is already in operational use." ] }, "de": { "title": "Simulation im modellbasierten Systems Engineering (MBSE)", "text": "Welche Aussagen über Simulation im MBSE sind korrekt?", "answers": [ "Simulationen können durch Systemmodelle gesteuert werden, um Verhalten und Leistung unter verschiedenen Szenarien zu bewerten.", "Simulationsergebnisse können zu Verifizierungs- und Validierungsnachweisen beitragen, wenn sie ordnungsgemäß geplant und dokumentiert werden.", "Die Simulation ersetzt in allen Fällen das physische Testen vollständig und macht Prototypen überflüssig.", "Die Simulation ist erst nach der Bereitstellung relevant, wenn sich das System bereits im operativen Einsatz befindet." ] } }, { "number": 87, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Technical Performance Measures (TPMs)", "text": "What is a Technical Performance Measure (TPM)?", "answers": [ "A critical technical parameter tracked over time to assess progress toward satisfying a requirement.", "A parameter monitored to ensure that technical trends remain acceptable during development and integration.", "A performance indicator related to stakeholder priorities but defined more quantitatively than opinion-based measures.", "A calendar date representing when a project phase is planned to finish according to the schedule." ] }, "de": { "title": "Technische Leistungsmessgrößen (Technical Performance Measures, TPMs)", "text": "Was ist eine technische Leistungsmessgröße (Technical Performance Measure, TPM)?", "answers": [ "Ein kritischer technischer Parameter, der über die Zeit verfolgt wird, um den Fortschritt bei der Erfüllung einer Anforderung zu beurteilen.", "Ein Parameter, der überwacht wird, um sicherzustellen, dass technische Trends während Entwicklung und Integration akzeptabel bleiben.", "Ein Leistungsindikator, der mit Stakeholder-Prioritäten zusammenhängt, aber quantitativer definiert ist als meinungsbasierte Maße.", "Ein Kalenderdatum, das angibt, wann eine Projektphase gemäß dem Terminplan abgeschlossen sein soll." ] } }, { "number": 88, "correct": [ 0 ], "confidence": "GOOD", "sources": "INCOSE_SEH5", "en": { "title": "Key Performance Parameters (KPPs)", "text": "What are Key Performance Parameters (KPPs)?", "answers": [ "A small set of critical performance attributes that must be achieved for the mission to be considered successful.", "Performance measures that are important and usually given high priority, even if some trade-offs may be considered.", "Key metrics that may influence staffing and organizational performance goals within the project.", "Indicators that completely replace the need for any other technical or programmatic measures." ] }, "de": { "title": "Key Performance Parameters (KPPs)", "text": "Was sind Key Performance Parameters (KPPs)?", "answers": [ "Eine kleine Gruppe kritischer Leistungsmerkmale, die erreicht werden müssen, damit die Mission als erfolgreich gilt.", "Leistungsmaße, die wichtig sind und in der Regel eine hohe Priorität erhalten, auch wenn einige Kompromisse in Betracht gezogen werden können.", "Wesentliche Kennzahlen, die die Personalbesetzung und die organisatorischen Leistungsziele innerhalb des Projekts beeinflussen können.", "Indikatoren, die die Notwendigkeit jeglicher anderer technischer oder programmatischer Maße vollständig ersetzen." ] } }, { "number": 89, "correct": [ 0 ], "confidence": "GOOD", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Measures of Effectiveness (MOEs) and Measures of Performance (MOPs)", "text": "What are Measures of Effectiveness (MOEs) and Measures of Performance (MOPs)?", "answers": [ "Measures of effectiveness assess how well the system meets mission objectives, while measures of performance describe specific system performance characteristics.", "Some MOEs and MOPs are influenced by schedule and operational constraints when assessing mission success.", "They can also be used to judge how well enabling systems and support processes contribute to system performance.", "Measures defined only in monetary terms, such as cost savings or profit margins." ] }, "de": { "title": "Measures of Effectiveness (MOEs) und Measures of Performance (MOPs)", "text": "Was sind Measures of Effectiveness (MOEs) und Measures of Performance (MOPs)?", "answers": [ "Measures of Effectiveness bewerten, wie gut das System die Missionsziele erfüllt, während Measures of Performance spezifische Leistungsmerkmale des Systems beschreiben.", "Einige MOEs und MOPs werden bei der Bewertung des Missionserfolgs durch Termin- und Betriebsrandbedingungen beeinflusst.", "Sie können auch verwendet werden, um zu beurteilen, wie gut unterstützende Systeme und Hilfsprozesse zur Systemleistung beitragen.", "Ausschließlich in monetären Größen definierte Kennzahlen, wie etwa Kosteneinsparungen oder Gewinnmargen." ] } }, { "number": 90, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Use of systems engineering (SE) metrics", "text": "Why are systems engineering technical and management measures important?", "answers": [ "They provide objective insight into progress and risk, supporting informed technical and management decisions.", "They can support reporting and compliance obligations, though their main value is for decision support.", "They can reduce the need for some status meetings by providing shared objective data for stakeholders.", "They are collected only at the very end of the project and are not used during project execution." ] }, "de": { "title": "Verwendung von Systems-Engineering-(SE-)Metriken", "text": "Warum sind technische und Management-Messgrößen des Systems Engineering wichtig?", "answers": [ "Sie bieten objektive Einblicke in Fortschritt und Risiko und unterstützen fundierte technische und Managemententscheidungen.", "Sie können Berichts- und Compliance-Pflichten unterstützen, wobei ihr Hauptwert jedoch in der Entscheidungsunterstützung liegt.", "Sie können den Bedarf an manchen Statusbesprechungen verringern, indem sie den Stakeholdern gemeinsame objektive Daten bereitstellen.", "Sie werden nur ganz am Ende des Projekts erhoben und werden während der Projektdurchführung nicht verwendet." ] } }, { "number": 91, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Role of the systems engineer", "text": "Core responsibilities of a systems engineer include:", "answers": [ "Understanding stakeholder needs and translating them into balanced technical solutions.", "Coordinating technical work across disciplines so that the overall solution remains coherent.", "Facilitating communication between groups, including non-technical stakeholders, on system-related topics.", "Defining corporate financial strategy and investment policy for the entire organization." ] }, "de": { "title": "Rolle des Systemingenieurs", "text": "Zu den Kernverantwortlichkeiten eines Systemingenieurs gehören:", "answers": [ "Stakeholder-Bedürfnisse zu verstehen und sie in ausgewogene technische Lösungen zu übersetzen.", "Die technische Arbeit über Disziplinen hinweg zu koordinieren, sodass die Gesamtlösung kohärent bleibt.", "Die Kommunikation zwischen Gruppen, einschließlich nicht-technischer Stakeholder, zu systembezogenen Themen zu erleichtern.", "Die Finanzstrategie und Investitionspolitik des Unternehmens für die gesamte Organisation zu definieren." ] } }, { "number": 92, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Systems engineering (SE) and configuration management", "text": "Why must systems engineers care about configuration management?", "answers": [ "Because architecture, requirements and interfaces must be under configuration control to maintain traceability and support change-impact analysis.", "Configuration control becomes especially critical in later phases when changes directly affect delivered items and formal documentation.", "Configuration records are often aligned with asset and financial records so that deliveries and versions can be tracked.", "Systems engineers should avoid configuration control to remain completely flexible and agile in making undocumented changes." ] }, "de": { "title": "Systems Engineering (SE) und Konfigurationsmanagement", "text": "Warum müssen sich Systemingenieure um das Konfigurationsmanagement kümmern?", "answers": [ "Weil Architektur, Anforderungen und Schnittstellen unter Konfigurationskontrolle stehen müssen, um die Nachverfolgbarkeit aufrechtzuerhalten und die Änderungsauswirkungsanalyse zu unterstützen.", "Die Konfigurationskontrolle wird in späteren Phasen besonders kritisch, wenn Änderungen unmittelbar gelieferte Artikel und die formale Dokumentation betreffen.", "Konfigurationsaufzeichnungen werden häufig mit Bestands- und Finanzaufzeichnungen abgeglichen, sodass Lieferungen und Versionen nachverfolgt werden können.", "Systemingenieure sollten die Konfigurationskontrolle vermeiden, um beim Vornehmen undokumentierter Änderungen völlig flexibel und agil zu bleiben." ] } }, { "number": 93, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Interface management", "text": "Why is interface management critical?", "answers": [ "Because many failures occur at interfaces, they must be clearly defined, controlled and verified.", "Internal interfaces within a single team may sometimes be managed less formally but still benefit from clear definitions and controls.", "Software interfaces may be recorded in APIs or code, but explicit management remains important for complex dependencies.", "Interfaces should be defined for the first time during maintenance, after major failures have already occurred." ] }, "de": { "title": "Schnittstellenmanagement", "text": "Warum ist das Schnittstellenmanagement kritisch?", "answers": [ "Weil viele Fehler an Schnittstellen auftreten, müssen diese klar definiert, kontrolliert und verifiziert werden.", "Interne Schnittstellen innerhalb eines einzelnen Teams können mitunter weniger formell verwaltet werden, profitieren aber dennoch von klaren Definitionen und Kontrollen.", "Softwareschnittstellen können in APIs oder Code erfasst werden, doch bleibt eine explizite Verwaltung bei komplexen Abhängigkeiten wichtig.", "Schnittstellen sollten erstmals während der Wartung definiert werden, nachdem bereits schwerwiegende Fehler aufgetreten sind." ] } }, { "number": 94, "correct": [ 0 ], "confidence": "GOOD", "sources": "SEBoK", "en": { "title": "Agile approaches and systems engineering (SE)", "text": "Which statement about agile approaches and systems engineering is correct?", "answers": [ "Agile practices can be combined with systems engineering principles to manage evolving requirements.", "Combining agile practices with systems engineering requires careful tailoring, especially in regulated environments with strong documentation needs.", "Traditional systems engineering has often been associated with larger up-front definition, but incremental approaches are also possible.", "Using agile methods removes the need for any formal verification activities, because testing is entirely implicit in iteration." ] }, "de": { "title": "Agile Ansätze und Systems Engineering (SE)", "text": "Welche Aussage über agile Ansätze und Systems Engineering ist korrekt?", "answers": [ "Agile Praktiken können mit Systems-Engineering-Prinzipien kombiniert werden, um sich verändernde Anforderungen zu handhaben.", "Die Kombination agiler Praktiken mit Systems Engineering erfordert eine sorgfältige Anpassung, insbesondere in regulierten Umgebungen mit hohem Dokumentationsbedarf.", "Das traditionelle Systems Engineering wurde oft mit einer umfangreicheren Vorab-Definition in Verbindung gebracht, doch inkrementelle Ansätze sind ebenfalls möglich.", "Die Verwendung agiler Methoden beseitigt die Notwendigkeit jeglicher formaler Verifizierungstätigkeiten, da das Testen vollständig implizit in der Iteration enthalten ist." ] } }, { "number": 95, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5", "en": { "title": "Trade studies", "text": "What is the purpose of a trade study?", "answers": [ "To evaluate alternatives using defined criteria in order to support a decision.", "To document candidate solutions and provide structured comparisons, even if final decisions also consider additional factors.", "To influence how stakeholder needs are prioritised when selecting among alternative solutions.", "To collect information indefinitely without ever converging on a chosen solution." ] }, "de": { "title": "Trade-off-Analysen", "text": "Was ist der Zweck einer Trade-off-Analyse?", "answers": [ "Alternativen anhand definierter Kriterien zu bewerten, um eine Entscheidung zu unterstützen.", "Kandidatenlösungen zu dokumentieren und strukturierte Vergleiche bereitzustellen, auch wenn endgültige Entscheidungen zusätzliche Faktoren berücksichtigen.", "Zu beeinflussen, wie Stakeholder-Bedürfnisse bei der Auswahl unter alternativen Lösungen priorisiert werden.", "Informationen unbegrenzt zu sammeln, ohne jemals auf eine ausgewählte Lösung zu konvergieren." ] } }, { "number": 96, "correct": [ 0, 1, 2 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;NASA_SEH", "en": { "title": "Technical reviews", "text": "Which are typical systems engineering technical reviews?", "answers": [ "System Requirements Review (SRR).", "Preliminary Design Review (PDR).", "Critical Design Review (CDR).", "Payroll Audit Review (PAR)." ] }, "de": { "title": "Technische Überprüfungen", "text": "Welche sind typische technische Überprüfungen im Systems Engineering?", "answers": [ "System Requirements Review (SRR).", "Preliminary Design Review (PDR).", "Critical Design Review (CDR).", "Payroll Audit Review (PAR)." ] } }, { "number": 97, "correct": [ 0 ], "confidence": "HIGH", "sources": "NASA_SEH", "en": { "title": "Test Readiness Review (TRR)", "text": "Purpose of a Test Readiness Review (TRR)?", "answers": [ "To confirm that test plans, procedures, configurations and resources are ready before major tests are conducted.", "To check that test facilities, configurations and resources remain suitable for the planned tests.", "To align planned tests with objectives and stakeholder expectations before execution begins.", "To approve human-resource budgets instead of focusing on technical test readiness." ] }, "de": { "title": "Test Readiness Review (TRR)", "text": "Zweck eines Test Readiness Review (TRR)?", "answers": [ "Zu bestätigen, dass Testpläne, -prozeduren, -konfigurationen und -ressourcen bereit sind, bevor wichtige Tests durchgeführt werden.", "Zu prüfen, ob Testeinrichtungen, -konfigurationen und -ressourcen für die geplanten Tests weiterhin geeignet sind.", "Die geplanten Tests vor Beginn der Durchführung mit den Zielen und Stakeholder-Erwartungen abzustimmen.", "Personalbudgets zu genehmigen, anstatt sich auf die technische Testbereitschaft zu konzentrieren." ] } }, { "number": 98, "correct": [ 0 ], "confidence": "GOOD", "sources": "NASA_SEH", "en": { "title": "Regression testing", "text": "Why is regression testing important?", "answers": [ "To ensure that changes or fixes have not introduced unintended side effects or broken existing functionality.", "To focus testing on areas affected by changes while re-running key existing tests to detect side effects.", "To complement configuration control by providing evidence that implemented changes behave as expected.", "To eliminate the need for risk management, because issues will always be discovered automatically by tests." ] }, "de": { "title": "Regressionstests", "text": "Warum sind Regressionstests wichtig?", "answers": [ "Um sicherzustellen, dass Änderungen oder Fehlerbehebungen keine unbeabsichtigten Nebenwirkungen eingeführt oder bestehende Funktionalität beeinträchtigt haben.", "Um Tests auf die von Änderungen betroffenen Bereiche zu konzentrieren und dabei zentrale bestehende Tests erneut auszuführen, um Nebenwirkungen zu erkennen.", "Um die Konfigurationssteuerung zu ergänzen, indem Nachweise dafür bereitgestellt werden, dass umgesetzte Änderungen sich wie erwartet verhalten.", "Um die Notwendigkeit des Risikomanagements zu beseitigen, da Probleme stets automatisch durch Tests entdeckt werden." ] } }, { "number": 99, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;NASA_SEH", "en": { "title": "Problem reporting and corrective action", "text": "Good systems engineering practice when an anomaly is discovered is to:", "answers": [ "Record it in a problem report, analyse the root cause and track corrective actions under configuration control.", "Triaging minor anomalies but still recording them so that patterns can be identified over time.", "Reviewing and, if appropriate, adjusting test conditions while still investigating potential design or requirement issues.", "Changing the software or hardware without recording the issue or updating any documentation." ] }, "de": { "title": "Problemmeldung und Korrekturmaßnahme", "text": "Gute Systems-Engineering-Praxis bei der Entdeckung einer Anomalie ist:", "answers": [ "Sie in einer Problemmeldung zu erfassen, die Grundursache zu analysieren und Korrekturmaßnahmen unter Konfigurationskontrolle nachzuverfolgen.", "Geringfügige Anomalien zu triagieren, aber dennoch zu erfassen, damit Muster über die Zeit erkannt werden können.", "Testbedingungen zu überprüfen und gegebenenfalls anzupassen, während mögliche Entwurfs- oder Anforderungsprobleme weiterhin untersucht werden.", "Die Software oder Hardware zu ändern, ohne das Problem zu erfassen oder eine Dokumentation zu aktualisieren." ] } }, { "number": 100, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK;INCOSE_SEH5", "en": { "title": "System of interest from different stakeholder views", "text": "Why can the system of interest differ between stakeholders?", "answers": [ "Because different stakeholders focus on different boundaries (component, system, system of systems, enterprise) based on their particular concerns.", "Standards often describe a reference view of the system of interest, but projects may emphasise different boundaries in practice.", "Systems engineers propose a definition of the system of interest but must reconcile it with stakeholder perspectives.", "The system of interest is always the smallest component that can be built or tested independently." ] }, "de": { "title": "System of Interest aus unterschiedlichen Stakeholder-Sichten", "text": "Warum kann sich das System of Interest zwischen Stakeholdern unterscheiden?", "answers": [ "Weil verschiedene Stakeholder sich auf der Grundlage ihrer besonderen Anliegen auf unterschiedliche Grenzen (Komponente, System, System von Systemen, Unternehmen) konzentrieren.", "Standards beschreiben oft eine Referenzsicht des System of Interest, aber Projekte können in der Praxis unterschiedliche Grenzen betonen.", "Systemingenieure schlagen eine Definition des System of Interest vor, müssen sie aber mit den Perspektiven der Stakeholder in Einklang bringen.", "Das System of Interest ist stets die kleinste Komponente, die unabhängig gebaut oder getestet werden kann." ] } }, { "number": 101, "correct": [ 1 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;ISO_15288;SEBoK", "en": { "title": "Scenario – conflicting stakeholder needs and requirements change", "text": "Halfway through development, a new stakeholder group requests a significant new capability that conflicts with some already-approved system requirements. Schedule and budget are tight. As the systems engineer, what is the most appropriate next step?", "answers": [ "Ask the development team to implement the requested capability informally if they can fit it in, and address any requirement inconsistencies later during testing.", "Initiate a formal change request, analyse the impact on requirements, architecture, cost, schedule and risk, and facilitate a decision with the relevant stakeholders before updating the baselines.", "Capture the new request as a future enhancement only, without analysing its impact, to avoid any disturbance to the current baselines.", "Direct the development team to implement the new capability immediately, without documentation or stakeholder communication, to avoid delay." ] }, "de": { "title": "Szenario – widersprüchliche Stakeholder-Bedürfnisse und Anforderungsänderung", "text": "Auf halbem Weg durch die Entwicklung fordert eine neue Stakeholder-Gruppe eine bedeutende neue Fähigkeit, die im Widerspruch zu einigen bereits genehmigten Systemanforderungen steht. Zeitplan und Budget sind knapp. Was ist als Systemingenieur der angemessenste nächste Schritt?", "answers": [ "Das Entwicklungsteam bitten, die geforderte Fähigkeit informell umzusetzen, falls es sie unterbringen kann, und etwaige Anforderungswidersprüche später während des Tests zu behandeln.", "Einen formellen Änderungsantrag einleiten, die Auswirkungen auf Anforderungen, Architektur, Kosten, Zeitplan und Risiko analysieren und eine Entscheidung mit den relevanten Stakeholdern herbeiführen, bevor die Baselines aktualisiert werden.", "Die neue Anforderung nur als zukünftige Erweiterung erfassen, ohne ihre Auswirkungen zu analysieren, um jede Störung der aktuellen Baselines zu vermeiden.", "Das Entwicklungsteam anweisen, die neue Fähigkeit sofort umzusetzen, ohne Dokumentation oder Stakeholder-Kommunikation, um Verzögerungen zu vermeiden." ] } }, { "number": 102, "correct": [ 2 ], "confidence": "HIGH", "sources": "SEBoK;INCOSE_SEH5", "en": { "title": "Scenario – verification vs validation choice", "text": "A prototype system has passed all laboratory tests against its documented requirements, but when representative users try it in a realistic environment, they struggle to complete their tasks. What does this situation primarily indicate you still need to address?", "answers": [ "Configuration management, because user difficulties mainly indicate uncontrolled configuration changes in the test setup.", "Additional verification, because it suggests some requirements were not thoroughly tested in laboratory conditions.", "Validation, because you must confirm the system is the right solution for the user needs and operational context, not only that it meets documented requirements.", "Disposal planning, because the prototype should be retired and replaced as soon as possible." ] }, "de": { "title": "Szenario – Wahl zwischen Verifizierung und Validierung", "text": "Ein Prototypsystem hat alle Labortests gegen seine dokumentierten Anforderungen bestanden, doch wenn repräsentative Nutzer es in einer realistischen Umgebung ausprobieren, fällt es ihnen schwer, ihre Aufgaben zu erledigen. Worauf weist diese Situation in erster Linie hin, das Sie noch angehen müssen?", "answers": [ "Konfigurationsmanagement, da Nutzerschwierigkeiten hauptsächlich auf unkontrollierte Konfigurationsänderungen im Testaufbau hindeuten.", "Zusätzliche Verifizierung, da dies nahelegt, dass einige Anforderungen unter Laborbedingungen nicht gründlich getestet wurden.", "Validierung, da Sie bestätigen müssen, dass das System die richtige Lösung für die Nutzerbedürfnisse und den operativen Kontext ist, und nicht nur, dass es die dokumentierten Anforderungen erfüllt.", "Entsorgungsplanung, da der Prototyp so bald wie möglich außer Betrieb genommen und ersetzt werden sollte." ] } }, { "number": 103, "correct": [ 3 ], "confidence": "HIGH", "sources": "SEBoK;INCOSE_SEH5", "en": { "title": "Scenario – selecting a life cycle model under high uncertainty", "text": "You are starting a project in a domain where user needs and enabling technologies are expected to change rapidly. Stakeholders accept some rework but want early feedback on concepts. Which life cycle approach best fits this situation?", "answers": [ "A disposal-focused life cycle model that concentrates effort at the end of life to manage decommissioning risks.", "A strictly sequential life cycle model with rigid stages to minimise change and rework, even if stakeholder understanding is still evolving.", "A life cycle model that focuses on late integration and testing to maximise the amount of work completed before stakeholders see the system.", "An iterative or incremental life cycle model that allows progressive refinement of requirements and architecture with frequent stakeholder feedback." ] }, "de": { "title": "Szenario – Auswahl eines Lebenszyklusmodells bei hoher Unsicherheit", "text": "Sie starten ein Projekt in einem Bereich, in dem sich Benutzerbedürfnisse und ermöglichende Technologien voraussichtlich rasch ändern werden. Die Stakeholder akzeptieren gewisse Nacharbeit, wünschen aber frühes Feedback zu Konzepten. Welcher Lebenszyklusansatz passt am besten zu dieser Situation?", "answers": [ "Ein entsorgungsorientiertes Lebenszyklusmodell, das den Aufwand am Lebensende konzentriert, um Außerbetriebnahmerisiken zu steuern.", "Ein streng sequenzielles Lebenszyklusmodell mit starren Phasen, um Änderungen und Nacharbeit zu minimieren, selbst wenn das Verständnis der Stakeholder noch reift.", "Ein Lebenszyklusmodell, das sich auf späte Integration und späte Tests konzentriert, um den Arbeitsumfang zu maximieren, bevor die Stakeholder das System sehen.", "Ein iteratives oder inkrementelles Lebenszyklusmodell, das eine schrittweise Verfeinerung von Anforderungen und Architektur mit häufigem Stakeholder-Feedback ermöglicht." ] } }, { "number": 104, "correct": [ 0 ], "confidence": "GOOD", "sources": "SEBoK", "en": { "title": "Scenario – system-of-systems integration challenge", "text": "Several independently managed systems must interoperate to provide an end-to-end capability. Each system has its own roadmap and funding. What is typically the biggest systems engineering challenge in this situation?", "answers": [ "Coordinating interfaces, capabilities and schedules across independently evolving systems while respecting their operational and managerial independence.", "Optimising the performance of a single constituent system, assuming others will adapt to its constraints.", "Freezing a common detailed design for all systems early, so that none of the independent programmes can change their plans without approval.", "Ensuring that all systems share the same owner, budget and configuration management system by changing their governance structure." ] }, "de": { "title": "Szenario – Integrationsherausforderung bei einem System von Systemen", "text": "Mehrere unabhängig gesteuerte Systeme müssen zusammenwirken, um eine durchgängige Fähigkeit bereitzustellen. Jedes System hat seine eigene Roadmap und Finanzierung. Was ist in dieser Situation typischerweise die größte Herausforderung im Systems Engineering?", "answers": [ "Koordinierung von Schnittstellen, Fähigkeiten und Zeitplänen über unabhängig voneinander weiterentwickelte Systeme hinweg, unter Wahrung ihrer operativen und managementbezogenen Unabhängigkeit.", "Optimierung der Leistung eines einzelnen Bestandteilsystems unter der Annahme, dass sich die anderen an seine Randbedingungen anpassen werden.", "Frühzeitiges Einfrieren eines gemeinsamen detaillierten Entwurfs für alle Systeme, sodass keines der unabhängigen Programme seine Pläne ohne Genehmigung ändern kann.", "Sicherstellen, dass alle Systeme denselben Eigentümer, dasselbe Budget und dasselbe Konfigurationsmanagementsystem teilen, indem ihre Governance-Struktur geändert wird." ] } }, { "number": 105, "correct": [ 0 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;NASA_SEH", "en": { "title": "Scenario – unexpected interface problem in integration", "text": "During integration testing, two subsystems fail to communicate correctly because each team implemented slightly different interpretations of the interface. What is the most appropriate systems engineering action?", "answers": [ "Update and clarify the interface definition (e.g., Interface Control Document), analyse the impact, and coordinate controlled updates to both subsystems under configuration management.", "Ask one team to adjust their implementation informally, without updating interface documentation, to avoid delaying integration.", "Change the test procedures to work around the mismatch and declare the interface verified if the test passes.", "Treat the issue as a minor anomaly and close it without action because both subsystems work correctly in isolation." ] }, "de": { "title": "Szenario – unerwartetes Schnittstellenproblem bei der Integration", "text": "Während des Integrationstests kommunizieren zwei Subsysteme nicht korrekt, weil jedes Team leicht unterschiedliche Auslegungen der Schnittstelle umgesetzt hat. Was ist die angemessenste Systems-Engineering-Maßnahme?", "answers": [ "Die Schnittstellendefinition aktualisieren und klarstellen (z. B. Interface Control Document), die Auswirkungen analysieren und kontrollierte Aktualisierungen beider Subsysteme unter Konfigurationsmanagement koordinieren.", "Ein Team bitten, seine Implementierung informell anzupassen, ohne die Schnittstellendokumentation zu aktualisieren, um eine Verzögerung der Integration zu vermeiden.", "Die Testprozeduren ändern, um die Diskrepanz zu umgehen, und die Schnittstelle als verifiziert erklären, wenn der Test bestanden wird.", "Das Problem als geringfügige Anomalie behandeln und ohne Maßnahme schließen, weil beide Subsysteme in Isolation korrekt funktionieren." ] } }, { "number": 106, "correct": [ 2 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;ISO_15288", "en": { "title": "Scenario – configuration management during rapid prototyping", "text": "A team is developing rapid prototypes of a new subsystem. Many small changes are made daily. After a promising demo, management asks, “Exactly which configuration did we just demonstrate?” but the team cannot answer. What should the systems engineer emphasise?", "answers": [ "Rely on test logs only, assuming they already contain enough information to fully reconstruct software and hardware versions.", "Delay configuration management until the design stabilises, and rely on developers’ memory to reconstruct the demonstrated configuration.", "Introduce lightweight but effective configuration identification and change control so each build and demo configuration is uniquely known and reproducible.", "Treat the demo as exploratory and explain that it is not necessary to know exactly what was demonstrated at this stage." ] }, "de": { "title": "Szenario – Konfigurationsmanagement beim Rapid Prototyping", "text": "Ein Team entwickelt schnelle Prototypen eines neuen Subsystems. Täglich werden viele kleine Änderungen vorgenommen. Nach einer vielversprechenden Vorführung fragt das Management: „Welche Konfiguration genau haben wir gerade vorgeführt?“, doch das Team kann dies nicht beantworten. Was sollte der Systemingenieur betonen?", "answers": [ "Sich allein auf Testprotokolle verlassen und annehmen, dass diese bereits genügend Informationen enthalten, um Software- und Hardwareversionen vollständig zu rekonstruieren.", "Das Konfigurationsmanagement verschieben, bis sich der Entwurf stabilisiert, und sich auf das Gedächtnis der Entwickler verlassen, um die vorgeführte Konfiguration zu rekonstruieren.", "Eine schlanke, aber wirksame Konfigurationsidentifikation und Änderungssteuerung einführen, sodass jede Build- und Vorführkonfiguration eindeutig bekannt und reproduzierbar ist.", "Die Vorführung als exploratorisch behandeln und erläutern, dass es in diesem Stadium nicht notwendig ist, genau zu wissen, was vorgeführt wurde." ] } }, { "number": 107, "correct": [ 3 ], "confidence": "HIGH", "sources": "SEBoK;INCOSE_SEH5", "en": { "title": "Scenario – late discovery of a safety issue", "text": "Late in integration, hazard analysis reveals a credible scenario that could lead to serious harm to users. Fixing it will likely impact cost and schedule. What is the most appropriate systems engineering response?", "answers": [ "Focus on meeting the original schedule by deferring any safety-related changes to a future upgrade once the system is deployed.", "Document the hazard for information only and proceed as planned, since the issue was discovered too late for practical mitigation.", "Transfer responsibility for all safety decisions to the customer, implementing only what they explicitly request without providing technical judgement.", "Assess the safety risk, evaluate mitigation options and bring a recommendation to the decision authority, giving safety priority while transparently presenting cost and schedule impacts." ] }, "de": { "title": "Szenario – späte Entdeckung eines Sicherheitsproblems", "text": "Spät in der Integration deckt eine Gefahrenanalyse ein plausibles Szenario auf, das zu schwerem Schaden für Benutzer führen könnte. Die Behebung wird voraussichtlich Kosten und Termine beeinflussen. Was ist die angemessenste Systems-Engineering-Reaktion?", "answers": [ "Sich auf die Einhaltung des ursprünglichen Terminplans zu konzentrieren, indem sicherheitsbezogene Änderungen auf ein künftiges Upgrade nach der Systemeinführung verschoben werden.", "Die Gefahr nur zur Information zu dokumentieren und wie geplant fortzufahren, da das Problem zu spät für eine praktikable Minderung entdeckt wurde.", "Die Verantwortung für alle Sicherheitsentscheidungen an den Kunden zu übertragen und nur das umzusetzen, was er ausdrücklich verlangt, ohne technisches Urteil beizusteuern.", "Das Sicherheitsrisiko zu bewerten, Minderungsoptionen zu evaluieren und der Entscheidungsinstanz eine Empfehlung vorzulegen, wobei der Sicherheit Priorität eingeräumt und die Kosten- und Terminauswirkungen transparent dargestellt werden." ] } }, { "number": 108, "correct": [ 0 ], "confidence": "HIGH", "sources": "SEBoK;INCOSE_SEH5", "en": { "title": "Scenario – adopting model-based systems engineering (MBSE)", "text": "A project team currently relies on long textual documents and is struggling with inconsistencies across requirements, architecture and interfaces. They plan to introduce model-based systems engineering. What is the most realistic primary benefit the systems engineer should highlight?", "answers": [ "Greater consistency and traceability across requirements and architecture, because models can provide a single, structured source of technical truth.", "Automatic elimination of all defects, because the presence of a formal model guarantees correctness by construction.", "The ability to completely stop producing any documentation, as the model alone will satisfy all stakeholders and contractual obligations.", "The possibility to remove the need for configuration management, since the model will implicitly track all changes and versions." ] }, "de": { "title": "Szenario – Einführung von Model-Based Systems Engineering (MBSE)", "text": "Ein Projektteam stützt sich derzeit auf lange textuelle Dokumente und kämpft mit Inkonsistenzen zwischen Anforderungen, Architektur und Schnittstellen. Es plant, Model-Based Systems Engineering einzuführen. Welchen realistischsten primären Nutzen sollte der Systemingenieur hervorheben?", "answers": [ "Größere Konsistenz und Nachverfolgbarkeit über Anforderungen und Architektur hinweg, weil Modelle eine einzige, strukturierte Quelle der technischen Wahrheit bereitstellen können.", "Automatische Beseitigung aller Fehler, weil das Vorhandensein eines formalen Modells die Korrektheit durch Konstruktion garantiert.", "Die Möglichkeit, die Erstellung jeglicher Dokumentation vollständig einzustellen, da das Modell allein alle Stakeholder und vertraglichen Verpflichtungen zufriedenstellt.", "Die Möglichkeit, die Notwendigkeit des Konfigurationsmanagements zu beseitigen, da das Modell implizit alle Änderungen und Versionen nachverfolgt." ] } }, { "number": 109, "correct": [ 1 ], "confidence": "HIGH", "sources": "SEBoK;ISO_15288", "en": { "title": "Scenario – using operational feedback to improve the system", "text": "After one year of operation, you receive systematic feedback that a particular maintenance task is taking much longer than expected and often requires additional tools. What is the most appropriate systems engineering use of this information?", "answers": [ "File the feedback only as evidence for audits, without linking it to requirements, architecture or future design decisions.", "Analyse the feedback, update maintenance concepts and, where justified, propose design or procedural changes, feeding lessons learned into future upgrades or systems.", "Treat the issue purely as a local operational problem and leave it entirely to maintenance teams to resolve informally.", "Assume the original maintainability requirements were unrealistic and remove them from the baseline without further analysis." ] }, "de": { "title": "Szenario – Nutzung von Betriebsrückmeldungen zur Verbesserung des Systems", "text": "Nach einem Betriebsjahr erhalten Sie systematische Rückmeldungen, dass eine bestimmte Wartungsaufgabe viel länger als erwartet dauert und oft zusätzliche Werkzeuge erfordert. Was ist die angemessenste Systems-Engineering-Nutzung dieser Information?", "answers": [ "Die Rückmeldung nur als Nachweis für Audits ablegen, ohne sie mit Anforderungen, Architektur oder zukünftigen Entwurfsentscheidungen zu verknüpfen.", "Die Rückmeldung analysieren, Wartungskonzepte aktualisieren und, wo gerechtfertigt, Entwurfs- oder Verfahrensänderungen vorschlagen sowie die Lessons Learned in zukünftige Upgrades oder Systeme einfließen lassen.", "Das Problem rein als lokales Betriebsproblem behandeln und es vollständig den Wartungsteams zur informellen Lösung überlassen.", "Annehmen, dass die ursprünglichen Wartbarkeitsanforderungen unrealistisch waren, und sie ohne weitere Analyse aus der Baseline entfernen." ] } }, { "number": 110, "correct": [ 2 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Scenario – distinguishing enabling systems from the system of interest", "text": "Your project is delivering a new satellite. Separate facilities and tools are being developed for assembly, integration, test and operator training. How should these facilities and tools be viewed from a systems engineering perspective?", "answers": [ "As temporary prototypes that should not be treated as systems and therefore do not require formal engineering or management.", "As part of the same delivered system of interest as the satellite, because they are essential for building and validating it.", "As enabling systems that provide services such as production, test and training to support the satellite across its life cycle, but are not part of the delivered satellite itself.", "As independent commercial products unrelated to the satellite project, even though they are used extensively during development." ] }, "de": { "title": "Szenario – Unterscheidung unterstützender Systeme vom betrachteten System", "text": "Ihr Projekt liefert einen neuen Satelliten. Für Montage, Integration, Test und Bedienerschulung werden separate Einrichtungen und Werkzeuge entwickelt. Wie sollten diese Einrichtungen und Werkzeuge aus Sicht des Systems Engineering betrachtet werden?", "answers": [ "Als temporäre Prototypen, die nicht als Systeme behandelt werden sollten und daher kein formales Engineering oder Management erfordern.", "Als Teil desselben gelieferten betrachteten Systems wie der Satellit, da sie für dessen Aufbau und Validierung unerlässlich sind.", "Als unterstützende Systeme, die Dienste wie Produktion, Test und Schulung bereitstellen, um den Satelliten über seinen Lebenszyklus hinweg zu unterstützen, aber nicht Teil des gelieferten Satelliten selbst sind.", "Als eigenständige kommerzielle Produkte, die mit dem Satellitenprojekt nichts zu tun haben, obwohl sie während der Entwicklung intensiv genutzt werden." ] } }, { "number": 111, "correct": [ 1 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Scenario – improving requirement quality", "text": "During a review, you notice several system requirements use vague terms such as “fast”, “user-friendly” and “reliable” without any measurable criteria. What is the most appropriate systems engineering action?", "answers": [ "Accept the wording as long as everyone in the meeting agrees informally on what the terms mean and move on to design.", "Work with stakeholders to refine these requirements into specific, correct, feasible and verifiable statements with clear measures or thresholds.", "Ask the design team to interpret the vague terms as they see fit, trusting that later testing can validate whether the system is acceptable.", "Move these requirements into an appendix labelled “informative” so they do not constrain the design." ] }, "de": { "title": "Szenario – Verbesserung der Anforderungsqualität", "text": "Während eines Reviews bemerken Sie, dass mehrere Systemanforderungen vage Begriffe wie „schnell“, „benutzerfreundlich“ und „zuverlässig“ ohne messbare Kriterien verwenden. Was ist die angemessenste Systems-Engineering-Maßnahme?", "answers": [ "Die Formulierung zu akzeptieren, solange sich alle im Meeting informell darauf einigen, was die Begriffe bedeuten, und mit dem Entwurf fortzufahren.", "Mit den Stakeholdern zusammenzuarbeiten, um diese Anforderungen zu spezifischen, korrekten, realisierbaren und verifizierbaren Aussagen mit klaren Maßen oder Schwellenwerten zu verfeinern.", "Das Entwurfsteam zu bitten, die vagen Begriffe nach eigenem Ermessen auszulegen, im Vertrauen darauf, dass spätere Tests validieren können, ob das System akzeptabel ist.", "Diese Anforderungen in einen als „informativ“ gekennzeichneten Anhang zu verschieben, damit sie den Entwurf nicht einschränken." ] } }, { "number": 112, "correct": [ 2 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Scenario – structuring a trade study", "text": "A team is comparing three architecture options, but their “trade study” consists only of informal discussion and personal preferences. No evaluation criteria or weights are defined. As the systems engineer, what is the best way to strengthen this decision?", "answers": [ "Ask each participant to rank the options subjectively and average the rankings to reach a consensus choice.", "Choose the option that appears cheapest upfront, as this will usually provide the best long-term value.", "Define clear evaluation criteria (e.g., performance, cost, risk, schedule), assign weights if appropriate, quantify or qualitatively rate each option, and document the rationale.", "Select the option that aligns most closely with the solution used on a previous project, without further analysis." ] }, "de": { "title": "Szenario – Strukturierung einer Trade-off-Analyse", "text": "Ein Team vergleicht drei Architekturoptionen, aber ihre „Trade-off-Analyse“ besteht nur aus informeller Diskussion und persönlichen Präferenzen. Es sind keine Bewertungskriterien oder Gewichtungen definiert. Was ist als Systemingenieur der beste Weg, diese Entscheidung zu stärken?", "answers": [ "Jeden Teilnehmer bitten, die Optionen subjektiv zu ordnen, und die Rangfolgen mitteln, um eine Konsensentscheidung zu erreichen.", "Die Option wählen, die im Voraus am günstigsten erscheint, da dies in der Regel den besten langfristigen Wert bietet.", "Klare Bewertungskriterien definieren (z. B. Leistung, Kosten, Risiko, Zeitplan), gegebenenfalls Gewichtungen zuweisen, jede Option quantitativ oder qualitativ bewerten und die Begründung dokumentieren.", "Die Option wählen, die am ehesten der in einem früheren Projekt verwendeten Lösung entspricht, ohne weitere Analyse." ] } }, { "number": 113, "correct": [ 1 ], "confidence": "HIGH", "sources": "SEBoK_RAM", "en": { "title": "Scenario – distinguishing reliability and availability", "text": "A service reports that the system rarely fails completely, but when it does, it takes a long time to restore. Users complain about long downtimes even though failure events are infrequent. Which quality attribute is most clearly being challenged?", "answers": [ "Reliability, because failures occur at all, even if rarely, which indicates a low probability of success over time.", "Availability, because long repair times reduce the proportion of time the system is up and able to perform its function.", "Maintainability, because the system cannot be restored to service quickly using ordinary procedures and resources.", "Security, because extended downtime exposes the system to increased risk of cyber attacks." ] }, "de": { "title": "Szenario – Unterscheidung von Zuverlässigkeit und Verfügbarkeit", "text": "Ein Dienst meldet, dass das System selten vollständig ausfällt, aber wenn es ausfällt, die Wiederherstellung lange dauert. Nutzer beklagen lange Ausfallzeiten, obwohl Ausfallereignisse selten sind. Welches Qualitätsattribut wird am deutlichsten in Frage gestellt?", "answers": [ "Zuverlässigkeit, weil überhaupt Ausfälle auftreten, wenn auch selten, was auf eine geringe Erfolgswahrscheinlichkeit über die Zeit hindeutet.", "Verfügbarkeit, weil lange Reparaturzeiten den Anteil der Zeit verringern, in der das System betriebsbereit ist und seine Funktion erfüllen kann.", "Wartbarkeit, weil das System mit gewöhnlichen Verfahren und Ressourcen nicht schnell wieder in Betrieb genommen werden kann.", "Sicherheit, weil längere Ausfallzeiten das System einem erhöhten Risiko von Cyberangriffen aussetzen." ] } }, { "number": 114, "correct": [ 3 ], "confidence": "HIGH", "sources": "INCOSE_SEH5;SEBoK;ISO_15288", "en": { "title": "Scenario – responding to a newly identified high risk", "text": "During early design, you identify a technical risk with high likelihood and high consequence if it occurs. What is the most appropriate systems engineering response?", "answers": [ "Note the risk in a log but proceed without any mitigation to avoid delaying design progress.", "Downgrade the assessed consequence so that the risk falls below management attention, since mitigation would be costly.", "Transfer the risk to another team by assigning them responsibility, without analysing treatment options.", "Develop and evaluate risk treatment options (e.g., design changes, redundancy, additional analyses), select a preferred mitigation plan, and monitor its effectiveness." ] }, "de": { "title": "Szenario – Reaktion auf ein neu identifiziertes hohes Risiko", "text": "Während des frühen Entwurfs identifizieren Sie ein technisches Risiko mit hoher Eintrittswahrscheinlichkeit und schwerwiegenden Folgen im Falle seines Eintretens. Was ist die angemessenste Systems-Engineering-Reaktion?", "answers": [ "Das Risiko in einem Register vermerken, aber ohne jegliche Minderung fortfahren, um Verzögerungen im Entwurfsfortschritt zu vermeiden.", "Die bewerteten Folgen herabstufen, sodass das Risiko unter die Aufmerksamkeitsschwelle des Managements fällt, da eine Minderung kostspielig wäre.", "Das Risiko an ein anderes Team übertragen, indem diesem die Verantwortung zugewiesen wird, ohne Behandlungsoptionen zu analysieren.", "Optionen zur Risikobehandlung entwickeln und bewerten (z. B. Entwurfsänderungen, Redundanz, zusätzliche Analysen), einen bevorzugten Minderungsplan auswählen und dessen Wirksamkeit überwachen." ] } }, { "number": 115, "correct": [ 2 ], "confidence": "HIGH", "sources": "ISO_15288", "en": { "title": "Scenario – transition vs operation", "text": "A new system has been delivered to the operational site, but operators report they have not received training, procedures are incomplete and initial data has not been loaded. Which process has most clearly not been adequately performed?", "answers": [ "The operation process, because the system is not being used effectively in its steady-state environment.", "The disposal process, because the legacy system has not yet been fully decommissioned.", "The transition process, because the system has not been properly prepared, handed over and enabled for operational use.", "The maintenance process, because no repairs or replacements have yet been carried out on the new system." ] }, "de": { "title": "Szenario – Übergang vs. Betrieb", "text": "Ein neues System wurde an den Betriebsstandort geliefert, aber die Betreiber melden, dass sie keine Schulung erhalten haben, Verfahren unvollständig sind und die Anfangsdaten nicht geladen wurden. Welcher Prozess wurde am deutlichsten nicht angemessen durchgeführt?", "answers": [ "Der Betriebsprozess, weil das System in seiner stationären Umgebung nicht wirksam genutzt wird.", "Der Entsorgungsprozess, weil das Altsystem noch nicht vollständig außer Betrieb genommen wurde.", "Der Übergangsprozess, weil das System nicht ordnungsgemäß vorbereitet, übergeben und für den Betrieb einsatzfähig gemacht wurde.", "Der Instandhaltungsprozess, weil am neuen System noch keine Reparaturen oder Ersetzungen durchgeführt wurden." ] } }, { "number": 116, "correct": [ 1 ], "confidence": "GOOD", "sources": "SEBoK", "en": { "title": "Scenario – end-to-end validation in a system-of-systems", "text": "You are responsible for a system-of-systems capability that relies on data from several independent systems. Each system has been tested locally, but stakeholders are unsure whether the overall mission objective can be achieved. What is the most appropriate next step?", "answers": [ "Assume the mission will succeed since each constituent system passed its own verification tests.", "Plan and execute end-to-end validation activities using realistic operational scenarios that involve all relevant systems together.", "Focus solely on additional unit tests within each system, because end-to-end tests are too complex and costly.", "Rely on written interface specifications as proof that end-to-end behaviour will match the intended mission needs." ] }, "de": { "title": "Szenario – durchgängige Validierung in einem System von Systemen", "text": "Sie sind verantwortlich für eine Fähigkeit eines Systems von Systemen, die auf Daten von mehreren unabhängigen Systemen beruht. Jedes System wurde lokal getestet, aber die Stakeholder sind unsicher, ob das Gesamtmissionsziel erreicht werden kann. Was ist der angemessenste nächste Schritt?", "answers": [ "Annehmen, dass die Mission erfolgreich sein wird, da jedes Bestandteilsystem seine eigenen Verifizierungstests bestanden hat.", "Durchgängige Validierungsaktivitäten unter Verwendung realistischer operativer Szenarien planen und durchführen, die alle relevanten Systeme gemeinsam einbeziehen.", "Sich ausschließlich auf zusätzliche Modultests innerhalb jedes Systems konzentrieren, weil durchgängige Tests zu komplex und kostspielig sind.", "Sich auf schriftliche Schnittstellenspezifikationen als Nachweis dafür verlassen, dass das durchgängige Verhalten den beabsichtigten Missionsbedürfnissen entsprechen wird." ] } }, { "number": 117, "correct": [ 2 ], "confidence": "GOOD", "sources": "INCOSE_SEH5;SEBoK", "en": { "title": "Scenario – combining agile iterations with requirements baselines", "text": "An agile team is delivering functionality in short iterations. Stakeholders want to ensure that evolving user stories still align with higher-level system requirements. What is the most appropriate systems engineering practice?", "answers": [ "Freeze all system requirements at the start and prohibit any changes to keep the baseline pure, even if user needs evolve.", "Treat user stories as the only authoritative requirements and discard the higher-level system requirement set.", "Maintain a baselined set of system requirements and trace user stories and backlog items to these requirements, updating both under controlled change when necessary.", "Allow user stories to evolve freely without traceability, relying on sprint reviews to catch any misalignment with system goals." ] }, "de": { "title": "Szenario – Kombination agiler Iterationen mit Anforderungs-Baselines", "text": "Ein agiles Team liefert Funktionalität in kurzen Iterationen. Die Stakeholder möchten sicherstellen, dass sich entwickelnde User Stories weiterhin mit den übergeordneten Systemanforderungen übereinstimmen. Was ist die angemessenste Systems-Engineering-Praxis?", "answers": [ "Alle Systemanforderungen zu Beginn einfrieren und jegliche Änderungen verbieten, um die Baseline rein zu halten, selbst wenn sich die Nutzerbedürfnisse weiterentwickeln.", "User Stories als die einzigen maßgeblichen Anforderungen behandeln und die übergeordnete Menge an Systemanforderungen verwerfen.", "Eine als Baseline festgelegte Menge an Systemanforderungen pflegen und User Stories sowie Backlog-Einträge auf diese Anforderungen zurückverfolgen, wobei beide bei Bedarf unter kontrollierter Änderung aktualisiert werden.", "Zulassen, dass sich User Stories ohne Rückverfolgbarkeit frei entwickeln, und sich auf Sprint-Reviews verlassen, um jede Abweichung von den Systemzielen zu erkennen." ] } }, { "number": 118, "correct": [ 0 ], "confidence": "HIGH", "sources": "ISO_15288;INCOSE_SEH5", "en": { "title": "Scenario – information management and outdated documents", "text": "Different teams are using different versions of interface specifications, and integration issues arise because some teams relied on outdated documents. What should the systems engineer focus on to address this problem?", "answers": [ "Strengthen information management so that authoritative versions are clearly identified, controlled, and easily accessible to all stakeholders.", "Ask each team to maintain its own local copy of documents and trust that they will synchronise changes informally.", "Rely solely on verbal coordination in regular meetings to communicate document changes, without formal control.", "Encourage teams to stop documenting interfaces so that integration can be handled dynamically during testing." ] }, "de": { "title": "Szenario – Informationsmanagement und veraltete Dokumente", "text": "Verschiedene Teams verwenden unterschiedliche Versionen von Schnittstellenspezifikationen, und es treten Integrationsprobleme auf, weil sich einige Teams auf veraltete Dokumente verlassen haben. Worauf sollte sich der Systemingenieur konzentrieren, um dieses Problem anzugehen?", "answers": [ "Das Informationsmanagement stärken, sodass maßgebliche Versionen klar identifiziert, gesteuert und für alle Stakeholder leicht zugänglich sind.", "Jedes Team bitten, seine eigene lokale Kopie der Dokumente zu pflegen, und darauf vertrauen, dass sie Änderungen informell abstimmen.", "Sich ausschließlich auf mündliche Abstimmung in regelmäßigen Besprechungen verlassen, um Dokumentänderungen ohne formale Steuerung zu kommunizieren.", "Die Teams ermutigen, Schnittstellen nicht mehr zu dokumentieren, sodass die Integration dynamisch während des Testens gehandhabt werden kann." ] } }, { "number": 119, "correct": [ 3 ], "confidence": "HIGH", "sources": "ISO_15288;SEBoK", "en": { "title": "Scenario – using lessons learned across projects", "text": "A post-project review has identified several valuable lessons about integration, verification and supplier coordination. Another project in the same organisation is starting with a similar scope. What is the most appropriate systems engineering action?", "answers": [ "Archive the lessons learned report in a project folder for compliance purposes and move on.", "Allow individual engineers to informally share their personal experience with the new project if they choose.", "Invite the new project team to a one-time briefing and rely solely on that meeting to transfer knowledge.", "Capture lessons in the organisation’s knowledge management system and ensure they are actively considered when tailoring processes and planning the new project." ] }, "de": { "title": "Szenario – Nutzung von Lessons Learned über Projekte hinweg", "text": "Ein Projektabschluss-Review hat mehrere wertvolle Erkenntnisse zu Integration, Verifizierung und Lieferantenkoordination identifiziert. Ein weiteres Projekt in derselben Organisation startet mit ähnlichem Umfang. Was ist die angemessenste Systems-Engineering-Maßnahme?", "answers": [ "Den Lessons-Learned-Bericht aus Compliance-Gründen in einem Projektordner zu archivieren und fortzufahren.", "Einzelnen Ingenieuren zu gestatten, ihre persönliche Erfahrung informell mit dem neuen Projekt zu teilen, wenn sie dies wünschen.", "Das neue Projektteam zu einem einmaligen Briefing einzuladen und sich ausschließlich auf dieses Meeting zur Wissensübertragung zu verlassen.", "Die Erkenntnisse im Wissensmanagementsystem der Organisation zu erfassen und sicherzustellen, dass sie beim Anpassen der Prozesse und bei der Planung des neuen Projekts aktiv berücksichtigt werden." ] } }, { "number": 120, "correct": [ 1 ], "confidence": "HIGH", "sources": "SEBoK_RAM;INCOSE_SEH5", "en": { "title": "Scenario – improving availability through design decisions", "text": "A system shows good reliability (few failures), but when failures occur, repair is complex and time-consuming, leading to low availability. Which design-focused action would most directly help improve availability?", "answers": [ "Increase the mission duration so that the proportion of downtime appears smaller over the whole life.", "Redesign components and access points to simplify diagnosis and replacement, and consider adding redundancy where justified.", "Add more detailed logging to the system without changing the physical design or maintenance concept.", "Focus testing exclusively on nominal scenarios to reduce the likelihood that failures are discovered during operation." ] }, "de": { "title": "Szenario – Verbesserung der Verfügbarkeit durch Entwurfsentscheidungen", "text": "Ein System zeigt eine gute Zuverlässigkeit (wenige Ausfälle), aber wenn Ausfälle auftreten, ist die Reparatur komplex und zeitaufwändig, was zu geringer Verfügbarkeit führt. Welche entwurfsorientierte Maßnahme würde am unmittelbarsten dazu beitragen, die Verfügbarkeit zu verbessern?", "answers": [ "Die Missionsdauer verlängern, sodass der Anteil der Ausfallzeit über die gesamte Lebensdauer kleiner erscheint.", "Komponenten und Zugangspunkte neu gestalten, um Diagnose und Austausch zu vereinfachen, und die Hinzufügung von Redundanz erwägen, wo dies gerechtfertigt ist.", "Dem System detailliertere Protokollierung hinzufügen, ohne den physischen Entwurf oder das Wartungskonzept zu ändern.", "Das Testen ausschließlich auf Nominalszenarien konzentrieren, um die Wahrscheinlichkeit zu verringern, dass Ausfälle während des Betriebs entdeckt werden." ] } } ] }