Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

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 ausdrü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
ASPEKTE FÜR SPEZIFIZIERUNG VON FUNKTIONALEN ANFORDERUNGEN
-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
ASPEKTE FÜR SPEZIFIZIERUNG VON QUALITÄTSANFORDERUNGEN
-Qualitätsmodelle und Standards -Leistungsanforderungen -Messbare Werte
27
ASPEKTE FÜR SPEZIFIZIERUNG VON KONTEXT UND GRENZEN
-Anforderungen können nur in Kontext und Grenzen verstanden werden -Domänenanforderungen und Annahmen spezifizieren -Angemessen dokumentieren und Redundanz vermeiden
28
ALLGEMEINE RICHTLINIEN FÜR DOKUMENTATION
-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
NATÜRLICHSPRACHIGE ARBEITSPRODUKTE-IMPLIZITE WAHRNEHMUNG UND TRANSFORMATIONSEFFEKTE
-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
VORLAGENBASIERTE ARBEITSPRODUKTE (TEMPLATES)
-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
Fehler beim Schreiben von Anforderungen
-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
GLOSSAR
-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
QUALITÄTSKRITERIEN FÜR ARBEITSPRODUKTE UND ANFORDERUNGEN
-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
WAS IST EIN „MODELL“?
-Abstrakte Darstellung der Realität -Grammatik und Sprachregeln wichtig für Modellverständnis: Syntax: Regeln/Darstellung, Semantik: Bedeutung der Darstellung -Verstehen der Modelleigenschaften notwendig f. korrekte Interpretation u. Anwendung
35
EIGENSCHAFTEN VON MODELLEN
-Bestimmter Zweck -Darstellung d. Realität -Verkürzte Realität - Nutzen hängt von der richtigen Menge der dargestellten Infos ab
36
Zielmodelle
-Und-Oder-Bäume -Zieldokumentation (textuell o. grafisch) wichtiger Startpunkt für Ermittlung
37
Kontextmodelle
-Datenflussdiagramme (prozessuale Interaktion mit einem System) -Use-Case-Diagramm (funktionale Aspekte und Systemgrenzen) -Abbildung von Benutzer und Systemschnittstellen mit beschriebenem System
38
Strukturdiagramme
-UML Klassendiagramm -Modellierung von Systemobjekten, deren Attribute und Beziehungen untereinander
39
Funktions-und Ablaufdiagramme
-UML Aktivitätsdiagramm +DFD & Use-Case-Diagramm -Funktionen und Fluss beschreiben Transformation von Ein-und Ausgabe
40
Verhaltensdiagramme
-UML ZUSTANDSDIAGRAMM -Beschreiben Verhalten, Status und Transitionen eines (Sub-)Systems
41
PROTOTYPEN IM REQUIREMENTS ENGINEERING
-Primär als Mittel für Anforderungserhebung und -Validierung -Explorative Prototypen mit verschiedenen Detailgraden (Fidelity) -Fokus auf Kosten vs. Wert (Trade-offs)
42
QUELLEN FÜR ANFORDERUNGEN
-Stakeholder -Dokumente -Systeme
43
ERMITTLUNG VON ANFORDERUNGEN
-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
KANO-MODELL
-Basisfaktorensind unterbewusste Anforderungen -Leistungsfaktorensind bewusste Anforderungen -Begeisterungsfaktorensind unbewusste Anforderungen
45
ERHEBUNGSTECHNIKEN
-Befragung -Kollaboration -Beobachtung -Artefakt-basiert
46
ENTWURFS-UND IDEENFINDUNGSTECHNIKEN
-Kreativitätstechniken -Entwurfstechniken -Design Thinking
47
AUFLÖSUNG VON KONFLIKTEN BEZÜGLICH ANFORDERUNGEN
Hauptprinzip: Konflikt auf Sachebene bringen -Konflikt-Identifikation -Konflikt-Analyse -Konflikt-Lösung -Lösungs-Dokumentation
48
KONFLIKTTYPEN IM REQUIREMENTS ENGINEERING
-Sachkonflikt -Datenkonflikt -Interessenkonflikt -Wertekonflikt -Beziehungskonflikt -Strukturkonflikt
49
VALIDIERUNG VON ANFORDERUNGEN
-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
VALIDIERUNGSTECHNIKEN
-Review-Techniken (statisch) - Inspektion -Explorative Techniken (dynamisch) - Tests -Probe-Entwicklung (statisch)
51
EINFLUSSFAKTOREN RE-Prozess
-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
WIE MAN RE-PROZESSE KONFIGURIERT
-Einflussfaktoren analysieren -Facetten-Kriterien beurteilen -Konfiguration wählen -Arbeitsprodukte bestimmen -Geeignete Praktiken auswählen
53
WAS IST UND WOFÜR BENÖTIGEN WIR REQUIREMENTS MANAGEMENT (RM)?
-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
VERSIONSKONTROLLE
-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
KONFIGURATION
-Konsistenter Satz von logisch zusammenhängenden Arbeitsprodukten/Anforderungen -Konfiguration als Arbeitsprodukt mit eindeutiger Identifikation dokumentiert - Anforderung+Version
56
BASISLINIEN
-spezielle Konfiguration mit stabilen und validierten Anforderungen
57
ATTRIBUTIERUNG VON ANFORDERUNGEN
-Sammlung von Metadaten für Anforderungen -Standard-und individuelle Attribute (Kontext) -Kein “Over-Engineering”
58
PRIORISIERUNGSTECHNIKEN
-Ad-hoc-Techniken -Analytische Techniken
59
VERFOLGBARKEIT (TRACEABILITY)
-Requirements Engineering schwer durchführbar ohne Nachverfolgung -Oft explizit gefordert für sicherheitskritische Systeme -Unerlässlich für Auswirkungsanalysevon Anforderungsänderungen
60
ARTEN VON VERFOLGBARKEIT
-Rückwärtsverfolgbarkeit/Pre-Traceability - Woher? (Quellen) -Verfolgbarkeit zwischen Anforderungen - Zusammenhang? -Vorwärtsverfolgbarkeit/Post-Traceability - Wofür?
61
CHANGE REQUESTS (CR) UND CHANGE CONTROL BOARD(CCB)
-CCB mit stabiler Strukturund cross-funktionalen Mitgliedern -Adaptiv, korrektiv o. ad-hoc (Hotfix) -Strukturierten Templates und Prozesse -Auswirkunsanalyse benötigt Verfolgbarkeit (Traceability)
62
WESENTLICHES ZUM MERKEN
-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