CPRE Flashcards
WAS IST REQUIREMENTS ENGINEERING (RE)?
-systematischer und disziplinierter Ansatz zur Spezifikation und Management von Anforderungen
-Stakeholder zufriedenstellen
-Risiko minimieren
-Kombination von Regeln und Elementen
WARUM BENÖTIGEN WIR REQUIREMENTS ENGINEERING?
-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
HAUPTTÄTIGKEITEN IM REQUIREMENTS ENGINEERING
-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
WIE WENDEN WIR REQUIREMENTS ENGINEERING „RICHTIG“ AN?
-Keine universelle Prozessbeschreibung für „WANN“ und „WIE“ –> “it depends”
WO BENÖTIGEN WIR REQUIREMENTS ENGINEERING?
-Volatility - laufende Änderung der Anforderungen
-Uncertainty - mangelnde Einschätzbarkeit
-Complexity - Unvorhersehbarkeit
-Ambiguity - Wahrscheinliche Missverständnisse
SYMPTOME VON MANGELHAFTEM REQUIREMENTS ENGINEERING
-Fehlende oder unklare Anforderungen
-Kommunikationsprobleme
-fehlende Methodik
-schlechter Projektverlauf
WAS IST EIN “SYSTEM”?
Einzelne Elemente die für bestimmten Zweck koordiniert werden
System besteht aus
-Softwarekomponenten
-Physische Elemente
-Organisatorische Elemente
Grundtypen von Systemen
-Cyber-physische Systeme
-Sozio-technische Systeme (beinhaltet Personen und Regeln) z.B Filter von Hate-Speech bei Facebook
WAS IST EINE „ANFORDERUNG”?
-Bedürfnis (Warum?)
-Funktion (Was?)
-schriftliches Artefakt (Wo?)
Anforderungsspezifikation = systematische Sammlung von Anforderungen, die Qualitätskriterien des RE erfüllt
KLASSIFIKATION VON ANFORDERUNGEN
-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)
ROLLE UND AUFGABEN EINES REQUIREMENTS ENGINEER
- Haupttätigkeiten RE
- Definition von RE-Prozessen
- RE-Praktiken auswählen und anwenden
- Lücke zwischen Problem und potentiellen Lösungen überbrücken
ZUGRUNDELIEGENDE KOMPETENZEN VON REQUIREMENTS ENGINEERS
-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
STAKEHOLDER
Person oder Organisation die mit System in Verbindung steht
-Wichtigste Quelle für Anforderungen und Feedback
-Aktives Management von Erwartungen
WERTORIENTIERUNG -MEHRWERT ALS MAß FÜR ANFORDERUNGEN
-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
GEMEINSAMES VERSTÄNDNIS -IMPLIZIT UND EXPLIZIT
-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
KONTEXT –SYSTEME EXISTIEREN NIE ISOLIERT
-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
SYSTEMKONTEXT-MODELL
-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
PROBLEM –ANFORDERUNG -LÖSUNG
-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
VALIDIERUNG –KEINE SPEZIFIKATION OHNE PRÜFUNG
-Kernaktivität im Requirements Engineering: nicht-validierte Anforderungen sind nutzlos
- Shift-left: So früh wie möglich mit Validierung beginnen
EVOLUTION –ÄNDERUNGEN SIND NATÜRLICH
-RE muss sich Anforderungsänderung bewusst sein - es passiert sowieso!
-Passende Ansätze nutzen
SYSTEMATISCHE UND DISZIPLINIERTE ARBEIT
-Kein “One-size-fits-all” Ansatz im Requirements Engineering
-Vergangenes RE angemessen reflektieren
-Nervöser Aktionismus und dauerhafter Panikmodus sind Gift
WAS IST EIN “ARBEITSPRODUKT”?
-Aufgezeichnetes Zwischen-o. Endergebnis erzeugt in einem Arbeitsprozess (=Artefakt)
-kann alles sein was Anforderungen ausdrückt (einzelner Satz oder Buch)
-kann andere Arbeitsprodukte enthalten
ABSTRAKTIONSEBENEN
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
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
ASPEKTE FÜR SPEZIFIZIERUNG VON QUALITÄTSANFORDERUNGEN
-Qualitätsmodelle und Standards
-Leistungsanforderungen
-Messbare Werte
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
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
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
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
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
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
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
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
EIGENSCHAFTEN VON MODELLEN
-Bestimmter Zweck
-Darstellung d. Realität
-Verkürzte Realität
- Nutzen hängt von der richtigen Menge der dargestellten Infos ab
Zielmodelle
-Und-Oder-Bäume
-Zieldokumentation (textuell o. grafisch) wichtiger Startpunkt für Ermittlung
Kontextmodelle
-Datenflussdiagramme (prozessuale Interaktion mit einem System)
-Use-Case-Diagramm (funktionale Aspekte und Systemgrenzen)
-Abbildung von Benutzer und Systemschnittstellen mit beschriebenem System
Strukturdiagramme
-UML Klassendiagramm
-Modellierung von Systemobjekten, deren Attribute und Beziehungen untereinander
Funktions-und Ablaufdiagramme
-UML Aktivitätsdiagramm
+DFD & Use-Case-Diagramm
-Funktionen und Fluss beschreiben Transformation von Ein-und Ausgabe
Verhaltensdiagramme
-UML ZUSTANDSDIAGRAMM
-Beschreiben Verhalten, Status und Transitionen eines (Sub-)Systems
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)
QUELLEN FÜR ANFORDERUNGEN
-Stakeholder
-Dokumente
-Systeme
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
KANO-MODELL
-Basisfaktorensind unterbewusste Anforderungen
-Leistungsfaktorensind bewusste Anforderungen
-Begeisterungsfaktorensind unbewusste Anforderungen
ERHEBUNGSTECHNIKEN
-Befragung
-Kollaboration
-Beobachtung
-Artefakt-basiert
ENTWURFS-UND IDEENFINDUNGSTECHNIKEN
-Kreativitätstechniken
-Entwurfstechniken
-Design Thinking
AUFLÖSUNG VON KONFLIKTEN BEZÜGLICH ANFORDERUNGEN
Hauptprinzip: Konflikt auf Sachebene bringen
-Konflikt-Identifikation
-Konflikt-Analyse
-Konflikt-Lösung
-Lösungs-Dokumentation
KONFLIKTTYPEN IM REQUIREMENTS ENGINEERING
-Sachkonflikt
-Datenkonflikt
-Interessenkonflikt
-Wertekonflikt
-Beziehungskonflikt
-Strukturkonflikt
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
VALIDIERUNGSTECHNIKEN
-Review-Techniken (statisch) - Inspektion
-Explorative Techniken (dynamisch) - Tests
-Probe-Entwicklung (statisch)
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
WIE MAN RE-PROZESSE KONFIGURIERT
-Einflussfaktoren analysieren
-Facetten-Kriterien beurteilen
-Konfiguration wählen
-Arbeitsprodukte bestimmen
-Geeignete Praktiken auswählen
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
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
KONFIGURATION
-Konsistenter Satz von logisch zusammenhängenden Arbeitsprodukten/Anforderungen
-Konfiguration als Arbeitsprodukt mit eindeutiger Identifikation dokumentiert - Anforderung+Version
BASISLINIEN
-spezielle Konfiguration mit stabilen und validierten Anforderungen
ATTRIBUTIERUNG VON ANFORDERUNGEN
-Sammlung von Metadaten für Anforderungen
-Standard-und individuelle Attribute (Kontext)
-Kein “Over-Engineering”
PRIORISIERUNGSTECHNIKEN
-Ad-hoc-Techniken
-Analytische Techniken
VERFOLGBARKEIT (TRACEABILITY)
-Requirements Engineering schwer durchführbar ohne Nachverfolgung
-Oft explizit gefordert für sicherheitskritische Systeme
-Unerlässlich für Auswirkungsanalysevon Anforderungsänderungen
ARTEN VON VERFOLGBARKEIT
-Rückwärtsverfolgbarkeit/Pre-Traceability - Woher? (Quellen)
-Verfolgbarkeit zwischen Anforderungen - Zusammenhang?
-Vorwärtsverfolgbarkeit/Post-Traceability - Wofür?
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)
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
