Vorbereitung - Set 4

Question

Welche Aufgaben umfasst das Konfliktmanagement im Requirements Engineering? (1 Antwort)

Answer 1

Konfliktidentifikation, Konfliktanalyse, Konfliktauflösung

Answer 2

Konfliktidentifikation, Konfliktanalyse, Konfliktauflösung, Dokumentation der Konfliktauflösung

Answer 3

Konfliktanalyse, Konfliktauflösung, Dokumentation der Konfliktauflösung

Answer 4

Konfliktidentifikation, Konfliktanalyse

Answer 5

Entscheidungskonflikt

Answer 6

Strukturkonflikt

Answer 7

Stakeholderkonflikt

Answer 8

Sachkonflikt

Answer 9

Wertekonflikt

Answer 10

Interessenkonflikt

Answer 11

Beziehungskonflikt

Answer 12

Strukturkonflikt

Answer 13

Sachkonflikt

Answer 14

Wertekonflikt

Answer 15

Interessenkonflikt

Answer 16

Beziehungskonflikt

Answer 17

Wertekonflikt

Answer 18

Sachkonflikt

Answer 19

Interessenkonflikt

Answer 20

Strukturkonflikt

Answer 21

Beziehungskonflikt

Answer 22

Interessenkonflikt

Answer 23

Wertekonflikt

Answer 24

Beziehungskonflikt

Answer 25

Sachkonflikt

Answer 26

Strukturkonflikt

Answer 27

Strukturkonflikt

Answer 28

Interessenkonflikt

Answer 29

Sachkonflikt

Answer 30

Wertekonflikt

Answer 31

Beziehungskonflikt

Answer 32

Strukturkonflikt

Answer 33

Interessenkonflikt

Answer 34

Wertekonflikt

Answer 35

Sachkonflikt

Answer 36

Beziehungskonflikt

Answer 37

Überstimmung

Answer 38

Ober-sticht-Unter

Answer 39

Abstimmung

Answer 40

Consider-all-Facts

Answer 41

Klassenbildung

Answer 42

Plus-Minus-Interesting

Answer 43

Unter-stich-Ober

Answer 44

Consider-important-Facts

Answer 45

Variantenbildung / Kompromiss / Entscheidungsmatrix

Answer 46

Wiederholte Behandlung von Konflikten.

Answer 47

Überprüfung von Konfliktauflösungen.

Answer 48

Beide Aussagen stimmen.

Answer 49

Informationen werden in der Regel zweckmäßig und richtig dokumentiert.

Answer 50

Wichtige zu dokumentierende Informationen sind nur schwer zu übersehen.

Answer 51

Zeitersparnis

Answer 52

Tippfehler werden vermieden.

Answer 53

Gleichartige Informationen sind immer am gleichen Ort dokumentiert.

Answer 54

Unnötige Informationen werden nicht dokumentiert.

Answer 55

Sind Veränderungen an Anforderungen, die nicht mehr geändert werden.

Answer 56

Beschreibt, wie bruchsicher eine Anforderung ist.

Answer 57

Ist der Umfang, in dem künftig noch Veränderungen bzgl. der Anforderungen erwartet werden.

Answer 58

schwankend

Answer 59

verfestigt

Answer 60

Zeitdauer für die Umsetzung.

Answer 61

Schaden bei nicht erfolgreicher Umsetzung.

Answer 62

Volatilität

Answer 63

Kosten für die Umsetzung.

Answer 64

Wichtigkeit.

Answer 65

Quality Function Deployment (QFD)

Answer 66

Top-Ten-Technik

Answer 67

Analytical Hierarchy Processing (AHP)

Answer 68

Zeit-Kosten-Analyse

Answer 69

Kano-Klassifikation

Answer 70

Wiegers`sche Priorisierungsmatrix

Answer 71

Ein-Kriteriums-Klassifikation

Answer 72

Top-Ten-Ranking

Answer 73

Kosten-Wert-Analyse

Answer 74

Not allowed

Answer 75

Nice-to-have

Answer 76

Identifikation von Goldrandlösungen in den Anforderungen

Answer 77

Wartung und Pflege

Answer 78

Nachweisbarkeit

Answer 79

Entscheidbarkeit

Answer 80

Auswirkungsanalyse

Answer 81

Zurechenbarkeit

Answer 82

Wiederverwendung

Answer 83

Identifikation von Goldranglösungen im System

Answer 84

Post-RS-Traceability

Answer 85

Traceability zwischen Anforderungen

Answer 86

Pre-RS-Traceability

Answer 87

Mid-RS-Traceability

Answer 88

Die Pre-RS-Traceability umfasst Verfolgbarkeitsinformationen von Anforderungen zu Artefakten, die im Projektverlauf den Anforderungen nachgelagert sind, z.B. Komponenten, Implementierung oder Testfälle.

Answer 89

Die Pre-RS-Traceability betrachtet Spezifikationsbeziehungen und Abhängigkeiten zwischen Anforderungen. Beispiele hierfür sind die Verfolgbarkeit, dass eine Anforderung eine andere Anforderung verfeinert, generalisiert oder ersetzt.

Answer 90

Unter der Pre-RS-Traceability werden Verfolgbarkeitsbeziehungen zu denjenigen Artefakten subsumiert, die der Anforderung im Projektverlauf vorverlagert sind, z.B. der Ursprung bzw. die Quelle einer Anforderung.

Answer 91

Die Post-RS-Traceability betrachtet Spezifikationsbeziehungen und Abhängigkeiten zwischen Anforderungen. Beispiele hierfür sind die Verfolgbarkeit, dass eine Anforderung eine andere Anforderung verfeinert, generalisiert oder ersetzt.

Answer 92

Unter der Post-RS-Traceability werden Verfolgbarkeitsbeziehungen zu denjenigen Artefakten subsumiert, die der Anforderung im Projektverlauf vorverlagert sind, z.B. der Ursprung bzw. die Quelle einer Anforderung.

Answer 93

Die Post-RS-Traceability umfasst Verfolgbarkeitsinformationen von Anforderungen zu Artefakten, die im Projektverlauf den Anforderungen nachgelagert sind, z.B. Komponenten, Implementierung oder Testfälle.

Answer 94

Die Traceability zwischen Anforderungen betrachtet Spezifikationsbeziehungen und Abhängigkeiten zwischen Anforderungen. Beispiele hierfür sind die Verfolgbarkeit, dass eine Anforderung eine andere Anforderung verfeinert, generalisiert oder ersetzt.

Answer 95

Die Traceability zwischen Anforderungen umfasst Verfolgbarkeitsinformationen von Anforderungen zu Artefakten, die im Projektverlauf den Anforderungen nachgelagert sind, z.B. Komponenten, Implementierung oder Testfälle.

Answer 96

Unter der Traceability zwischen Anforderungen werden Verfolgbarkeitsbeziehungen zu denjenigen Artefakten subsumiert, die der Anforderung im Projektverlauf vorverlagert sind, z.B. der Ursprung bzw. die Quelle einer Anforderung.

Answer 97

Verfolgbarkeitsmatrizen

Answer 98

Verfolgbarkeitsreferenzen

Answer 99

Verfolgbarkeitsgraphen

Answer 100

Verfolgbarkeitsklassifikation

Answer 101

Kano-Referenzen

Answer 102

Textuelle Referenzen und Hyperlinks

Answer 103

Abgestimmtheit

Answer 104

Grundlage für Rücksetzen

Answer 105

Konsistenz

Answer 106

Nicht veränderbar

Answer 107

Sachlogischer Zusammenhang

Answer 108

Eindeutige Identifikation

Answer 109

Abschätzung des Realisierungsaufwands

Answer 110

Grundlage zur Planung von Auslieferungsstufen

Answer 111

Vergleichen mit Konkurrenzprodukten

Answer 112

Fehlverhalten des Systems im Betrieb

Answer 113

Evolution des Kontexts

Answer 114

Fehler oder Unvollständigkeiten in Anforderungen

Answer 115

Entwicklers

Answer 116

Softwaretesters

Answer 117

Change-Control-Boards

Answer 118

Anforderungsmanagers

Answer 119

Projektmanagers

Answer 120

Bestimmung des Aufwands zur Umsetzung eines Änderungsauntrags (ggf. Beauftragung Dritter mit der Aufwandsanalyse)

Answer 121

Beurteilung der Änderungsanträge, z.B. im Hinblick auf das Verhältnis von Aufwand zum Nutzen

Answer 122

Zuordnung der angenommenen Änderungsanträge zu Änderungsprojekten

Answer 123

Definition von Anforderungsänderungen bzw. Definition neuer Anforderungen auf der Grundlage der Änderungsanträge

Answer 124

Entscheidung über Annahme/Ablehnung eines Änderungsantrags

Answer 125

Klassifikation eingehender Änderungsanträge

Answer 126

Priorisierung der angenommenen Anforderungsänderungen

Answer 127

Änderungsmanager, Auftraggeber, Architekt, Entwickler, Konfigurationsmanager, Kunde, Nutzervertreter, Produktmanager, Projektmanager, Qualitätsbeauftragter, Requirements Engineer

Answer 128

Änderungsmanager, Auftraggeber, Architekt, Entwickler, Konfigurationsmanager, Kundenvertreter, Nutzervertreter, Produktmanager, Projektmanager, Qualitätsbeauftragter, Requirements Engineer

Answer 129

Änderungsmanager, Auftraggeber, Architekt, Entwickler, Konfigurationsmanager, Kundenvertreter, Nutzer, Produktmanager, Projektmanager, Qualitätsbeauftragter, Requirements Engineer

Answer 130

Änderungsmanager, Auftraggeber, Architekt, Entwickler, Konfigurationsmanager, Kundenvertreter, Nutzervertreter, Produktmanager, Projektmanager, Requirements Engineer

Answer 131

Verantwortlich für die Änderung von Anforderungen

Answer 132

Verantwortlich für Kommunikation und Dokumentation von Entscheidungen

Answer 133

Im Fall von Konflikten zwischen den Beteiligten zu vermitteln und getroffene Entscheidungen mit den jeweiligen Parteien abzustimmen.

Answer 134

Identifikator, Titel, Beschreibung, Begründung, Erklärung, Datum, Antragsteller, Priorität aus Sicht des Antragstellers

Answer 135

Identifikator, Titel, Beschreibung, Begründung, Datum, Antragsteller, Priorität aus Sicht des Antragstellers

Answer 136

Identifikator, Titel, Beschreibung, Begründung, Antragsteller, Priorität aus Sicht des Antragstellers

Answer 137

Identifikator, Titel, Beschreibung, Begründung, Datum, Antragsteller

Answer 138

Adaptive Anforderungsänderung

Answer 139

Ausnahmeänderung (Hotfix)

Answer 140

Korrektive Anforderungsänderung

Answer 141

Modifizierte Anforderungsänderung

Answer 142

Ein Änderungsantrag wird dieser Kategorie zugeordnet, wenn es sich um eine Änderung handelt, die unbedingt und unmittelbar umzusetzen ist. Ausnahmeänderungen können sowohl korrektiv als auch adaptiv sein.

Answer 143

Ein Änderungsantrag wird dieser Kategorie zugeordnet, wenn die beantrage Änderung eine Anpassung des Systems erfordert. Ursache für eine diese Anforderungsänderung kann beispielsweise eine Veränderung im Kontext sein, z.B. neue Technologie verfügbar oder veränderte Systemgrenzen.

Answer 144

Ein Änderungsantrag wird dieser Kategorie zugeordnet, wenn die Grundlage für den Änderungsantrag ein Fehlverhalten des Systems im Betrieb und dessen Ursache auf einen Fehler in den Anforderungen zurückzuführen ist.

Answer 145

Ein Änderungsantrag wird dieser Kategorie zugeordnet, wenn es sich um eine Änderung handelt, die unbedingt und unmittelbar umzusetzen ist. Ausnahmeänderungen können sowohl korrektiv als auch adaptiv sein.

Answer 146

Ein Änderungsantrag wird dieser Kategorie zugeordnet, wenn die Grundlage für den Änderungsantrag ein Fehlverhalten des Systems im Betrieb und dessen Ursache auf einen Fehler in den Anforderungen zurückzuführen ist.

Answer 147

Ein Änderungsantrag wird dieser Kategorie zugeordnet, wenn die beantrage Änderung eine Anpassung des Systems erfordert. Ursache für diese Anforderungsänderung kann beispielsweise eine Veränderung im Kontext sein, z.B. neue Technologie verfügbar oder veränderte Systemgrenzen.

Answer 148

Ein Änderungsantrag wird dieser Kategorie zugeordnet, wenn die Grundlage für den Änderungsantrag ein Fehlverhalten des Systems im Betrieb und dessen Ursache auf einen Fehler in den Anforderungen zurückzuführen ist.

Answer 149

Ein Änderungsantrag wird dieser Kategorie zugeordnet, wenn es sich um eine Änderung handelt, die unbedingt und unmittelbar umzusetzen ist. Ausnahmeänderungen können sowohl korrektiv als auch adaptiv sein.

Answer 150

Ein Änderungsantrag wird dieser Kategorie zugeordnet, wenn die beantrage Änderung eine Anpassung des Systems erfordert. Ursache für eine diese Anforderungsänderung kann beispielsweise eine Veränderung im Kontext sein, z.B. neue Technologie verfügbar oder veränderte Systemgrenzen.

Answer 151

Produktmetriken

Answer 152

Prozessmetriken

Answer 153

Projektmetriken

Answer 154

Testmetriken

Answer 155

Fehler in Anforderungen

Answer 156

Änderungsrate von Anforderungen

Answer 157

Fehler in Anforderungen

Answer 158

Änderungsrate von Anforderungen

Answer 159

Standard-Büroanwendungen

Answer 160

Testwerkzeuge

Answer 161

Spezialisierte Werkzeuge

Answer 162

Requirements-Engineering-Sicht

Answer 163

Prozesssicht

Answer 164

Projektsicht

Answer 165

Betriebswirtschaftliche Sicht

Answer 166

Benutzersicht

Answer 167

Usabilitysicht

Answer 168

Technische Sicht

Answer 169

Testersicht

Answer 170

Projektmanagersicht

Answer 171

Anbietersicht / Produktsicht

Answer 172

Das Glossar sollte mit den Stakeholdern abgestimmt sein

Answer 173

Die Einträge des Glossars müssen eine einheitliche Struktur aufweisen

Answer 174

Das Glossar muss zentral verwaltet werden

Answer 175

Verfolgbarkeit schaffen

Answer 176

Verantwortlichkeit schaffen

Answer 177

Das Glossar muss dezentral verwaltet werden

Answer 178

Die Herkunft der Begriffe sollte im Glossar enthalten sein

Answer 179

Das Glossar muss projektbegleitend gepflegt werden

Answer 180

Das Glossar muss verbindlich verwendet werden

Answer 181

Das Glossar muss allgemein zugänglich sein

Answer 182

Klassendiagramm

Answer 183

Datenflussdiagramm

Answer 184

Zustandsdiagramm

Answer 185

Aktivitätsdiagramm

Answer 186

Entity-Relationship-Diagramm

Answer 187

Datenflussdiagramm

Answer 188

Kontextdiagramm

Answer 189

Statecharts

Answer 190

Entity - Relationship - Diagramm

Answer 191

Zustandsdiagramm

Answer 192

Use - Case - Diagramm

Answer 193

Aktivitätsdiagramm

Answer 194

Klassendiagramm

Answer 195

Aktivitätsdiagramm

Answer 196

Und-Oder-Bäume

Answer 197

Zustandsdiagramm

Answer 198

Datenflussdiagramm

Answer 199

Datenflussdiagramm

Answer 200

Use - Case - Diagramm

Answer 201

Zustandsdiagramm

Answer 202

Klassendiagramm

Answer 203

Aktivitätsdiagramm

Answer 204

Die Grauzone der Systemabgrenzung muss im Laufe des Projekts aufgelöst werden.

Answer 205

Ein Kontextdiagramm hilft bei der Auflösung der Grauzone.

Answer 206

Noch nicht getroffene Entscheidungen über Schnittstellen zwischen System und Kontext beeinflussen die Grauzone.

Answer 207

Fehlerhafte oder unklare Ziele beinflussen die Grauzone.

Answer 208

Geschäftsprozesse sind keine nützliche Quelle für die Betrachtung des Systemkontexts.

Answer 209

Die Aspekte im Systemkontext haben keinen Einfluss auf das zu entwickelte System.

Answer 210

Der Kontext umfasst andere Systeme, die mit dem geplannten System später interagieren.

Answer 211

Der Kontext beschreibt nicht die Systemumgebung

Answer 212

Das System soll eine Schnittstelle zu anderen Biblioteken zur Verfügung stellen, um andere Ausleihdaten empfangen zu können.

Answer 213

Die Anforderung beschreibt eine selbstständige Systemaktivität.

Answer 214

Die Anforderung beschreibt eine Schnittstellenanforderung

Answer 215

Das System soll eigenständig eine Anfrage an die anderen Bibliotheken stellen können.

Answer 216

In der Anforderung sind Universalquantoren.

Answer 217

Der Prozess wird zu einem Ereignis gemacht (Nominalisierung).

Answer 218

In der Anforderung sind Substantive ohne Bezugsindex.

Answer 219

Die Anforderung beschreibt eine Benutzterinteraktion.

Answer 220

Die Anforderung ist verständlich geschrieben und besitzt keine sprachlichen Effekte.

Answer 221

Die Anforderung ist im Passiv formuliert und beinhaltet unspezifierte Prozesswörter.

Answer 222

Die Anforderung defniert nicht, wer die Nummern speichert.

Answer 223

Der Satz erfüllt nicht die Definition einer Anforderung.

Answer 224

Unvollständig spezifierte Bedingungen

Answer 225

Nominalisierung

Answer 226

Unvollständig spezifierte Prozesswörter

Answer 227

Passivformlierungen

	Criado por T T mais de 7 anos atrás

Próximo

Vorbereitung - Set 4

Descrição

Resumo de Recurso

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Questão 21

Questão 22

Questão 23

Questão 24

Questão 25

Questão 26

Questão 27

Questão 28

Questão 29

Questão 30

Questão 31

Questão 32

Questão 33

Questão 34

Questão 35

Questão 36

Questão 37

Questão 38

Questão 39

Questão 40

Questão 41

Questão 42

Questão 43

Questão 44

Questão 45

Questão 46

Questão 47

Questão 48

Questão 49

Questão 50

Questão 51

Questão 52

Semelhante