Kapitel 1 - RM
Anforderungs-Landschaft
Welche Abstraktion Grade bei Dokumentation?
Attribuierung
Welche Anf. Sind abgenommen
Aus welcher Quelle?
Priorisierung
Welche Anf. Sind wichtig und dringend?
Versionsverwaltung
Welche Anf. Gehört zur Baseline?
Verfolgbarkeit (traceability)
Welche Testfälle gehören zur Anf.?
Variantenmanagement
Unterschied zwischen Varianten
Berichtwesen
Wie lange dauert ein CR
Maßnahmen zur Verbesserung geholfen?
-> RMP legt schon zu Bericht Regeln und Infos fest, zudem Rollen und verwendete Werkzeuge
-> RM ist Teil von RE
Verwaltung =
Speichern von Anf.
Strukturieren und Aufbereiten von Anf.
Änderungen verwalten, durchführen, nachverfolgen
Kapitel 2 - Req. Information Model
-> Welche Aspekte (Dimensionen) hat eine Anforderungslandschaft?
Anforderungsart
Funktional (was?)
Qualität (wie?)
Randbedingungen (Einschränkung, nicht verhandelbar)
Lösungsunabhängigkeit
Ziele (Geschäft, System, Produkt)
Szenarien (Geschäft, Benutzer, System)
lösungsorientierte Anf. (Feature, Geschäftsregel, Benutzeranf., GUI Anf., betriebliche Anf., Systemanf.)
Detailierungsebene
mehrere Abstasktionsebenen (Konsistent!!)
solange bis weitere Detailierung mehr Kosten als Nutzen verursacht
so lange bis alle Anf. eindeutig prüfbar/testbar sind
Darstellungsform
Natürliche Sprache (Prosa)
Strukturierter Text (Template, Schablone)
Modellbasierte Notation (UML, Feautre-Baum)
Formale Beschreibung (mathem. Funktion)
-> RIM visualisiert (graphisch) die Anf. Landschaft mit zusatz-Infos:
Landesprache
Attribute
Sichten
Bewertungskriterien
Rollen
Verfolgbarkeitsbeziehung
Dokumentierung
-> Darstellung als Klassendiagram, ER-Diagramm,…
Kapitel 3 - Attribuierung und Sichten
Wichtige Attribute
ID
Prio
Abhängigkeit
Risiko
Quelle
Begründung
Schwierigkeit
Art
(Freigabe)
(last modified)
Attributierungsschema
Menge aller definierten Attribute einer Klasse von Anforderungen
Beschreibt relevante Attribute (Attributname, Format/Werte, Default-Wert, Pflichtfeld?)
Vor Beginn der Anf.-Dokumentation zu erstellen und möglichst nicht mehr ändern!
Quelle für Attribute identifizieren
Attribute auswählen
Attributwerte /-Eigenschaften definieren
Abhängigkeiten definieren
Erfassungsunterstützung bereitstellen
Dokumentieren
Arten von Sichten
Selektiv (Ausgeblendete Objekte)
Projektiv (Ausgeblendete Attribute)
Verdichtend (Komprimiert für Dashboard, Bericht)
Kombination
Kapitel 4 - Bewerten und Priorisieren
Bewertungs-Kriterien
Kano-Kategorie (Basis (must), Performance, Begeisterung, Unerheblich)
Juristische Verbindlichkeit
Kosten
Kritikalität
Stabilität
Bewertungs-Eigenschaften
Wertebereich
Wer darf die Bewertung machen?
Frühester/Spätester Zeitpunkt der Bewertung
Bewertung <-> Prioriät
Bewertung durch RM mit oben genannten Kriterien
Priorität mit Stakeholder zusammen
Prio-Techniken
Ad-hoc:
schnell, geringe Kosten/Aufwand, gut skalierbar
Triage (muss, kann, nicht), Ranking, Top 10, Planning Poker, 1 Kriterien Klassifikation, 2 Kriterien Klassifikation, Kano-Klassifikation, 100$ Technik (Punkte verteilen), MoSCoW (must, should, can, won’t)
Analytisch:
bei kritischen Anf., nicht gut skalierbar
Wieger’sche Matrix, Analytical Hierarchy Process (AHP, leichteste da vergleich von immer nur 2 Anf.. Aber sehr komplex, da zeitaufwändig: n(n-1/2 Vergleiche zu machen)
Kapitel 5 - Versions- & Änderungsmanagement
Lebenszyklus einer Anf.:
anlegen, prüfen, ggf. ändern od. löschen, freigeben, implementieren, testen, release, und wieder von vorne
neue Version von Anf. wenn sie zurückgewiesen wurde und angepasst werden muss
Versionskontrolle:
wann/was/wie oft geändert?
wie branchen
wo letzte BL sehen
für ges. Dokument oder für einzelne Anf. (aufwändig, Werkzeug notwendig)
Version
Eine Version ist eine Weiterentwicklung eines Arbeitsprodukts oder einer Anforderung.
Es gibt immer nur eine gültige Version pro Arbeitsprodukt in einem bestimmten Kontext.
Eine neue Version entsteht durch Änderungen an einem bestehenden Produktzustand.
-> ID.3 Software v1.0 → v1.1
Konfiguration
Eine Konfiguration ist ein unveränderlicher Zustand eines Arbeitsprodukts oder einer Sammlung von Arbeitsprodukten.
Änderungen führen zu einer neuen Konfiguration oder Version.
Konfigurationen sind wichtig für Rückverfolgbarkeit und Wiederherstellung.
-> ID.3 mit Software v1.1, Batterie 58 kWh, Farbe Blau
Baseline
Eingefrorene Referenzversion, dient als stabiler Ausgangspunkt für weitere Entwicklung.
-> ID.3 Software v1.0 als Basis für Tests
Release
Veröffentliche Konfiguration, bereit zur Auslieferung oder Nutzung.
-> ID.3 Software v1.1 offiziell freigegeben
Änderungstypen
korrektiv (wegen von Fehler)
adaptiv (wegen d von neuen Rhamenbedingungen/Kontext)
ausnahme (wegen schadhaftem Verhalten)
bugs (Umsetzung fehlerhaft)
defect (Implementierung korrekt, aber Verhalten nicht wie von Stakeholder gewünscht)
innovation (neue Anforderungen an System)
tuning (neue Anforderungen an Stabilität/performance etc.)
-> Frage “wer trägt die Kosten” kann damit beantwortet werden
-> stabil = keine Änderung mehr
funktionale Ziele
Anforderungen für festes Release
aus stabiler Anf. Gruppe
-> volatil = Änderungen zu erwarten
Qualitätsanforderungen
nicht zugewiesene Anf.
aus volatiler Anf. Gruppe
CR Ablehnung wegen:
Änderung zu aufwändig
Wiederspruch mit anderer Anf.
zu hohes Risiko bezügl. Stabilität
-> CCB für formale Bewertung ist Empfehlung, kein muss
Kapitel 6 - Verfolgbarkeit = Traceability, Nachverfolgbarkeit
Pre / Rück -> Quelle: Stakeholder, vogelagerte Anf., Idee, Gesetz
zwischen Anf. -> verfeinerung
Post / Nach -> Umsetzung: Architektur, Entwicklungs Anf., Test
-> Typen: Bedingung, Inhalt, Dokumentation, Abstraktion, Evolution
-> Darstellung: Inline (textuell, Hyperlink), Orthogonal (Verfolgbarkeitsmatrix, -Tabelle)
-> Info über: Auswirkung, Testbadeckung, Wiederverwendbarkeit, Änderungshäufigkeit, Umsetzungsbelegbarkeit
-> Bewertung: Vollständig?, Richtig?
Kapitel 7 - Varianten
Variante
Konkrete Ausprägung eines Produkts, bei der für jeden Variationspunkt eine Entscheidung getroffen wurde.
-> ID.3 GTX mit Sportpaket und großer Batterie
Branching (Verzweigung)
Ein Branch ist eine Kopie einer Konfiguration oder Version eines Arbeitsprodukts, die als Ausgangspunkt für parallele Entwicklungen dient.
Branches ermöglichen parallele Entwicklungslinien, z. B. für unterschiedliche Produktvarianten.
Sie können später wieder mit dem Hauptzweig (Main Line) zusammengeführt werden.
-> ID.3 Branch für Flottenkunden mit Sonderfunktionen
Variantenmanagement / Konfiguration im Kontext von Varianten
Eine Variante ist eine konkrete Ausprägung eines Produkts, bei der für jeden Variationspunkt eine spezifische Entscheidung getroffen wurde.
Varianten entstehen durch Auswahl von Features oder Eigenschaften aus einem Feature-Modell.
Produktfamilie
Eine Produktfamilie besteht aus mehreren Produkten, die komplementär und miteinander verbunden sind.
Die Produkte teilen oft eine gemeinsame Plattform oder Architektur.
-> ID.3, ID.4, ID.5, ID.Buzz
Produktlinie
Eine Produktlinie umfasst verschiedene Varianten eines Produkts, die durch Übernahme, Variation oder Weglassen von Eigenschaften entstehen.
Ziel ist es, unterschiedliche Marktbedürfnisse mit minimalem Entwicklungsaufwand zu bedienen.
-> ID.3 Standard, ID.3 GTX, ID.3 mit größerer Batterie.
Bindezeitpunkt
Zeitpunkt, zu dem eine Entscheidung über eine Variante getroffen wird. Früh = vor Entwicklung, spät = zur Laufzeit.
Früh: Auswahl vor Entwicklung oder Produktion (HW Variante)
Mittel: Auswahl während Zusammenbau/Inbetriebnahme/Systemstart
Spät: Auswahl während der Laufzeit (SW Feature)
Merkmal (Feature)
Ein Feature ist eine sichtbare funktionale oder nicht-funktionale Eigenschaft oder Qualität, die ein System oder Produkt auszeichnet und für Stakeholder von Bedeutung ist.
Features helfen dabei, Anforderungen modular und wiederverwendbar zu strukturieren.
Modellierung mit FODA (Feature Oriented Domain Analysis)
Dokumentation
implizit: “oder”, “sowohl … als auch” -> nicht eindeutig
explizit: Schlüsselwort “Variantionspunkt” oder separates Modul
Darstellungsformen
Textuelle Zuordnung (unübersichtlich)
Explizite Zuordnung in Matrix (gut skalierbar)
Indirekte Zuordnung Zuweisung in versch. Attributen. Details in extra Matrix
grafische Merkmalsmodellierung (für komplexe produkte geeinget)
Kapitel 7 - Merkmalsmodellierung
Auto hat Hülle und Antrieb ggf. Kupplung und/oder Navigation
Hülle entweder Limousine oder Coupé
Navigation entweder Portable oder Build in
Antrieb Benzin oder E-Motor oder beides
-> Wenn Coupé dann keine portable Navigation
-> Wenn Kupplung dann Limousine
Kapitel 8 - Berichtwesen
Ampel-Darstellung (Tabelle oder Bild mit Beschreibung)
Zeitdiagramm (Fertigstellungsgrad als Liniendiagramm oder Status als Balkendiagramm)
Formlos (Email), Mit Vorlage, Autom. erzeugt
mit Projektname, Datum, Versionsnummer, Berichtszeitraum, Ersteller und Empfänger, Freigabestatus, Gesamtstatus, Fachlicher Inhalt
Goal Question Metric
Systematische Vorgehensweise zur Identifikation von Kennzahlen, um nur zielführende Kennzahlen für Berichte zu definieren
Risiken/Probleme
helfen bei Management Entscheidungen -> Falsche Inhalte haben folgen
zu viele Infos od. keine Details vorhanden / Datenqualität
Datenschutz
Kaptiel 9 - Management von RE Prozessen
-> Qualitätskriterien:
-> Parameter:
-> Dokumentation:
-> KPV (Kontinuierliche Proszessverbesserung:
-> Messgrößen:
Kapitel 10 - Agile Projekte
Scrum:
Kapitel 11 - Werkzeug
Zuletzt geändertvor 14 Tagen
