Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

MPU > CPRE > Flashcards

CPRE Flashcards

1
Q

WAS IST REQUIREMENTS ENGINEERING (RE)?

A

-systematischer und disziplinierter Ansatz zur Spezifikation und Management von Anforderungen
-Stakeholder zufriedenstellen
-Risiko minimieren
-Kombination von Regeln und Elementen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

WARUM BENÖTIGEN WIR REQUIREMENTS ENGINEERING?

A

-Lieferung von anspruchsgerechten Produkten und Qualitäten
-Ermöglichen konstruktiver Zusammenarbeit und Kundenzufriedenheit
-Vermeidung von impliziten Missverständnissen durch explizite Ziel-und Systemdefinition
-Reduzierung von Aufwand und Kosten

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

HAUPTTÄTIGKEITEN IM REQUIREMENTS ENGINEERING

A

-Anforderungs-Ermittlung: Quellen identifizieren, Prozess definieren, Relevante Anforderungen erheben
-Anforderungs-Dokumentation: Anforderungen explizit aufnehmen, Anforderungsspezifikation erstellen, Arbeitsprodukte verwalten
-Anforderungs-Validierung: Arbeitsprodukte prüfen, Akzeptanz und Abnahme sicherstellen, Fehler aufdecken und korrigieren
-Anforderungs-Management: Lifecycle Management, Versionierung und Konfiguration, Änderungskontrolle (CR)

Aufnehmen, aufschreiben, validieren, managen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

WIE WENDEN WIR REQUIREMENTS ENGINEERING „RICHTIG“ AN?

A

-Keine universelle Prozessbeschreibung für „WANN“ und „WIE“ –> “it depends”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

WO BENÖTIGEN WIR REQUIREMENTS ENGINEERING?

A

-Volatility - laufende Änderung der Anforderungen
-Uncertainty - mangelnde Einschätzbarkeit
-Complexity - Unvorhersehbarkeit
-Ambiguity - Wahrscheinliche Missverständnisse

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

SYMPTOME VON MANGELHAFTEM REQUIREMENTS ENGINEERING

A

-Fehlende oder unklare Anforderungen
-Kommunikationsprobleme
-fehlende Methodik
-schlechter Projektverlauf

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

WAS IST EIN “SYSTEM”?

A

Einzelne Elemente die für bestimmten Zweck koordiniert werden

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

System besteht aus

A

-Softwarekomponenten
-Physische Elemente
-Organisatorische Elemente

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Grundtypen von Systemen

A

-Cyber-physische Systeme
-Sozio-technische Systeme (beinhaltet Personen und Regeln) z.B Filter von Hate-Speech bei Facebook

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

WAS IST EINE „ANFORDERUNG”?

A

-Bedürfnis (Warum?)
-Funktion (Was?)
-schriftliches Artefakt (Wo?)

Anforderungsspezifikation = systematische Sammlung von Anforderungen, die Qualitätskriterien des RE erfüllt

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

KLASSIFIKATION VON ANFORDERUNGEN

A

-Funktionale Anforderung (FR) - Beschreibung der Funktion (qualitativ) (FR/NFR erweitern, definieren, bedingen einander)
-Qualitäts-Anforderung (NFR) - metrische Anforderungen (quantitativ)
-Randbedingung - unveränderbar (schränken FR/NFR ein)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

ROLLE UND AUFGABEN EINES REQUIREMENTS ENGINEER

A
  • Haupttätigkeiten RE
  • Definition von RE-Prozessen
  • RE-Praktiken auswählen und anwenden
  • Lücke zwischen Problem und potentiellen Lösungen überbrücken
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

ZUGRUNDELIEGENDE KOMPETENZEN VON REQUIREMENTS ENGINEERS

A

-Kommunikation und Moderation
-Analytisches Denken
-Empathie und reflektierende Kommunikation
-Neutralität und Konfliktlösungs-Fähigkeit
-Führungsstärke und Selbstvertrauen
-Überzeugungs-Fähigkeit und Motivation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

STAKEHOLDER

A

Person oder Organisation die mit System in Verbindung steht

-Wichtigste Quelle für Anforderungen und Feedback
-Aktives Management von Erwartungen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

WERTORIENTIERUNG -MEHRWERT ALS MAß FÜR ANFORDERUNGEN

A

-Anforderungen müssen Zweck erfüllen
-muss langfristig Wert schaffen
-Aufwand bemisst sich nach Auswirkungen wenn ich es nicht mache und Relevanz für Stakeholder

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

GEMEINSAMES VERSTÄNDNIS -IMPLIZIT UND EXPLIZIT

A

-Erfolgreiche Systementwicklung ist nicht möglich ohne gemeinsame Basis
-Explizites gemeinsames Verständnis - dokumentierte und vereinbarte Anforderungen (planbasierten Prozessen)
-Implizites gemeinsames Verständnis - gemeinsames Wissen über Bedürfnisse, Visionen, Kontext (Agile RE-Prozesse)
-gewisses Maß an implizites Wissen vorteilhaft
-Konzentration auf relevantes gemeinsames Verständnis
-Glossare, Prototypen und existierende Systeme als Bezugspunkt

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

KONTEXT –SYSTEME EXISTIEREN NIE ISOLIERT

A

-Anforderungen nie isoliert betrachten, immer im System/Beziehungen zu einander
-Nicht ohne grundlegende Bewertung des Kontexts starten
-System, Umfang, Grenzen, Schnittstellen bestimmen und an Umgebung anpassen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

SYSTEMKONTEXT-MODELL

A

-System: alles was kontrolliert werden kann und mir gehört
-Systemgrenze: Ziel: scharfe Abgrenzung zwischen System und umgebenden Kontext - Eliminierung Grauzonen
-Schnittstellen: Interaktionspunkt zwischen System und Kontext
-Kontext: Dokumente, Gesetze, Stakeholder - beeinflussen System
-Kontextgrenze
-Irrelevante Umgebung

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

PROBLEM –ANFORDERUNG -LÖSUNG

A

-Probleme, Anforderungen und Lösungen sollten nicht voneinander isoliert werden
-Fokus auf Separation of Concerns - Abgrenzung von Problemen
-„Ende-zu-Ende“ denken und in realistischen Schritten agieren

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

VALIDIERUNG –KEINE SPEZIFIKATION OHNE PRÜFUNG

A

-Kernaktivität im Requirements Engineering: nicht-validierte Anforderungen sind nutzlos
- Shift-left: So früh wie möglich mit Validierung beginnen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

EVOLUTION –ÄNDERUNGEN SIND NATÜRLICH

A

-RE muss sich Anforderungsänderung bewusst sein - es passiert sowieso!
-Passende Ansätze nutzen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

SYSTEMATISCHE UND DISZIPLINIERTE ARBEIT

A

-Kein “One-size-fits-all” Ansatz im Requirements Engineering
-Vergangenes RE angemessen reflektieren
-Nervöser Aktionismus und dauerhafter Panikmodus sind Gift

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

WAS IST EIN “ARBEITSPRODUKT”?

A

-Aufgezeichnetes Zwischen-o. Endergebnis erzeugt in einem Arbeitsprozess (=Artefakt)
-kann alles sein was Anforderungen ausrückt (einzelner Satz oder Buch)
-kann andere Arbeitsprodukte enthalten

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

ABSTRAKTIONSEBENEN

A

Ein Arbeitsprodukt kann andere verschiedene Arbeitsprodukte enthalten

-Geschäft: Geschäftsanforderungs-Spezifikation, Visionsdokumente, Strategiepapiere
-System: Systemanforderungs-Spezifikation
-Komponente: Technische Anforderungs-Spezifikation

-Kein universeller „richtiger” Grad für Anforderungsdetails
-Höhere Abstraktionsebenen zuerst dann niedrigere
-Arbeitsprodukte auf höheren Systemebenen können auf niedrigeren Systemebenen verfeinert werden
-Detaillierungsgrad hängt von Kontext ab

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

ASPEKTE FÜR SPEZIFIZIERUNG VON FUNKTIONALEN ANFORDERUNGEN

A

-Struktur und Daten - Statische Struktur von System und Daten
-Funktion und Ablauf - Beschreibung Funktionen + Datenfluss zwischen Funktionen zur Erzeugung der gewünschten Ergebnisse
-Zustand und Verhalten - Beschreibung des zustandsabhängigen Verhaltens und Reaktion auf Änderungen

26
Q

ASPEKTE FÜR SPEZIFIZIERUNG VON QUALITÄTSANFORDERUNGEN

A

-Qualitätsmodelle und Standards
-Leistungsanforderungen
-Messbare Werte

27
Q

ASPEKTE FÜR SPEZIFIZIERUNG VON KONTEXT UND GRENZEN

A

-Anforderungen können nur in Kontext und Grenzen verstanden werden
-Domänenanforderungen und Annahmen spezifizieren
-Angemessen dokumentieren und Redundanz vermeiden

28
Q

ALLGEMEINE RICHTLINIEN FÜR DOKUMENTATION

A

-Arbeitsprodukt-Typ sollte dem Zweck angemessen sein
-Arbeitsprodukte angemessen strukturieren (Standards)
-Redundanz vermeiden durch Referenzen (statt Wiederholungen) - auf Inhalte verweisen
-Inkonsistenzen zwischen Arbeitsprodukten vermeiden
-Konsistente Terminologie - Glossar!
-Angemessener Zugriff und Transparenz - nicht jeder muss alles sehen

29
Q

NATÜRLICHSPRACHIGE ARBEITSPRODUKTE-IMPLIZITE WAHRNEHMUNG UND TRANSFORMATIONSEFFEKTE

A

-ausdrucksstark und flexibel –> benötigen keine Vorbildung
-nicht für technische Dokumentation geeignet –> Standards für Erfassung
-Individuen sind beeinflusst durch Sprache, implizites Wissen, Kultur, Erfahrungen
-Transformationseffekte zum Vermeiden bzw. Auflösen

30
Q

VORLAGENBASIERTE ARBEITSPRODUKTE (TEMPLATES)

A

-gut strukturierte Arbeitsprodukte - eine Anforderung pro Satz, konsistente Terminologie
-Vorteil: klare, wiederverwendbare Struktur
-Nachteil: mechanische Verwendung

-Satzschablonen (muss, sollte, kann)
-Formularvorlagen (z.B. Tabellarische Beschreibung mit vordefinierten Eigenschaften)
-Dokumentvorlagen

31
Q

Fehler beim Schreiben von Anforderungen

A

-unvollständige Beschreibungen
-unspezifische Substantive
-unvollständige Bedingungen
-unvollständige Vergleiche
-passive Formulierungen- kein handelndes Substantiv (wer macht etwas?)
-Universalquantoren: alle, immer, nie
-Nomialisierung: Substantivierung von Verben (Authtifizierung statt authentifizieren) - beinhaltet oft unvollständige Beschreibung

32
Q

GLOSSAR

A

-Zentrales Mittel für gemeinsamen Verständnisses zur verwendeten Terminologie
-Definitionen und notwendigen Beschreibungen für relevanten Begriffe
-Regeln für Erstellung, Verwendung und Anpassung müssen eingehalten werden

33
Q

QUALITÄTSKRITERIEN FÜR ARBEITSPRODUKTE UND ANFORDERUNGEN

A

-RE strebt nach strukturierten Anforderungen, die bestimmte Qualitätskriterien erfüllen
-Standards ermöglichen Fülle von Qualitätskriterien, aber kein genereller Konsens
-Wertorientierten Ansatz: Qualitätskriterien sollen geschaffenen Wert entsprechen

34
Q

WAS IST EIN „MODELL“?

A

-Abstrakte Darstellung der Realität
-Grammatik und Sprachregeln wichtig für Modellverständnis: Syntax: Regeln, Semantik: Bedeutung
-Verstehen der Modelleigenschaften notwendig f. korrekte Interpretation u. Anwendung

35
Q

EIGENSCHAFTEN VON MODELLEN

A

-Bestimmter Zweck
-Darstellung d. Realität
-Verkürzte Realität

36
Q

Zielmodelle

A

-Und-Oder-Bäume
-Zieldokumentation (textuell o. grafisch) wichtiger Startpunkt für Ermittlung

37
Q

Kontextmodelle

A

-Datenflussdiagramme
-Use-Case-Diagramm
-Kontextdiagramm
-Strukturelle Eingliederung in Umgebung mit Interaktionen zu Nutzern und Systemen

38
Q

Strukturdiagramme

A

-UML Klassendiagramm
-Modellierung von Systemobjekten, deren Attribute und Beziehungen untereinander

39
Q

Funktions-und Ablaufdiagramme

A

-UML Aktivitätsdiagramm
-Funktionen und Fluss beschreiben Transformation von Ein-und Ausgabe

40
Q

Verhaltensdiagramme

A

-UML ZUSTANDSDIAGRAMM
-Beschreiben Verhalten, Status und Transitionen eines (Sub-)Systems

41
Q

PROTOTYPEN IM REQUIREMENTS ENGINEERING

A

-Primär als Mittel für Anforderungserhebung und -Validierung
-Explorative Prototypen mit verschiedenen Detailgraden (Fidelity)
-Fokus auf Kosten vs. Wert (Trade-offs)

42
Q

QUELLEN FÜR ANFORDERUNGEN

A

-Stakeholder
-Dokumente
-Systeme

43
Q

ERMITTLUNG VON ANFORDERUNGEN

A

-Implizite Wünsche, Bedürfnisse, Forderungen und Erwartungen in explizite, verständliche, erkennbare und überprüfbare Anforderungen umwandeln
-Richtige Ermittlungstechniken (oder Mix) unter gegebenen Umständen anwenden

44
Q

KANO-MODELL

A

-Basisfaktorensind unterbewusste Anforderungen
-Leistungsfaktorensind bewusste Anforderungen
-Begeisterungsfaktorensind unbewusste Anforderungen

45
Q

ERHEBUNGSTECHNIKEN

A

-Befragung
-Kollaboration
-Beobachtung
-Artefakt-basiert

46
Q

ENTWURFS-UND IDEENFINDUNGSTECHNIKEN

A

-Kreativitätstechniken
-Entwurfstechniken
-Design Thinking

47
Q

AUFLÖSUNG VON KONFLIKTEN BEZÜGLICH ANFORDERUNGEN

A

Hauptprinzip: Konflikt auf Sachebene bringen

-Konflikt-Identifikation
-Konflikt-Analyse
-Konflikt-Lösung
-Lösungs-Dokumentation

48
Q

KONFLIKTTYPEN IM REQUIREMENTS ENGINEERING

A

-Sachkonflikt
-Datenkonflikt
-Interessenkonflikt
-Wertekonflikt
-Beziehungskonflikt
-Strukturkonflikt

49
Q

VALIDIERUNG VON ANFORDERUNGEN

A

-Vorgelagerte Qualitätssicherung reduziert nachgelagerten Ausschuss
-Kontinuierliche Verbesserung: Entwicklung und Betrieb überwachen und analysieren

-Die richtigen Stakeholder einbeziehen
-Trennung von Fehlererkennung und Fehlerkorrektur
-Validierung aus unterschiedlichen Sichten
-Wiederholte Validierung

50
Q

VALIDIERUNGSTECHNIKEN

A

-Review-Techniken (statisch) - Inspektion
-Explorative Techniken (dynamisch) - Tests
-Probe-Entwicklung (statisch)

51
Q

EINFLUSSFAKTOREN RE-Prozess

A

-Eignung im Gesamtprozess
-Entwicklungskontext
-Stakeholder-Verfügbarkeit u. -Fähigkeiten
-Gemeinsames Verständnis
-Komplexität u. Kritikatlität
-Randbedingungen
-Verfügbare Zeit und Budgets
-Volatilität von Anforderungen
-Erfahrung der Requirements Engineers

52
Q

WIE MAN RE-PROZESSE KONFIGURIERT

A

-Einflussfaktoren analysieren
-Facetten-Kriterien beurteilen
-Konfiguration wählen
-Arbeitsprodukte bestimmen
-Geeignete Praktiken auswählen

53
Q

WAS IST UND WOFÜR BENÖTIGEN WIR REQUIREMENTS MANAGEMENT (RM)?

A

-Bestehende Anforderungen und Arbeitsprodukte verwalten - Lifecycle Management
-Wert des RM liegt in erhöhter Systemeffizienz und -Effektivität
-“Have the end in mind” Anforderungen verwalten = Risiken verwalten

54
Q

VERSIONSKONTROLLE

A

-Ziel: Änderungen in der Historie systematisch verstehen und ggf. rückgängig machen
-Versionsnummern beinhalten typischerweise Version und Inkrement
-Eindeutige Identifizierung jeder Version
-Klare Beschreibung jeder Änderung
-Regelung für Speicherung

55
Q

KONFIGURATION

A

-Konsistenter Satz von logisch zusammenhängenden Arbeitsprodukten/Anforderungen
-Konfiguration als Arbeitsprodukt mit eindeutiger Identifikation dokumentiert - Anforderung+Version

56
Q

BASISLINIEN

A

-spezielle Konfiguration mit stabilen und validierten Anforderungen

57
Q

ATTRIBUTIERUNG VON ANFORDERUNGEN

A

-Sammlung von Metadaten für Anforderungen
-Standard-und individuelle Attribute (Kontext)
-Kein “Over-Engineering”

58
Q

PRIORISIERUNGSTECHNIKEN

A

-Ad-hoc-Techniken
-Analytische Techniken

59
Q

VERFOLGBARKEIT (TRACEABILITY)

A

-Requirements Engineering schwer durchführbar ohne Nachverfolgung
-Oft explizit gefordert für sicherheitskritische Systeme
-Unerlässlich für Auswirkungsanalysevon Anforderungsänderungen

60
Q

ARTEN VON VERFOLGBARKEIT

A

-Rückwärtsverfolgbarkeit/Pre-Traceability - Woher? (Quellen)
-Verfolgbarkeit zwischen Anforderungen - Zusammenhang?
-Vorwärtsverfolgbarkeit/Post-Traceability - Wofür?

61
Q

CHANGE REQUESTS (CR) UND CHANGE CONTROL BOARD(CCB)

A

-CCB mit stabiler Strukturund cross-funktionalen Mitgliedern
-Adaptiv, korrektiv o. ad-hoc (Hotfix)
-Strukturierten Templates und Prozesse
-Auswirkunsanalyse benötigt Verfolgbarkeit (Traceability)

62
Q

WESENTLICHES ZUM MERKEN

A

-RE ist domänen- und prozess- unabhängig
-RE erfüllt Stakeholder-Bedürfnisse
-RE erfordert systematische Disziplin
-RE verwendet angemessene Arbeitsprodukte
-RE stellt KEINEN “One-fits-all” Ansatz dar

MPU (2 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions