Grundlegende Prinzipien des RE Flashcards
Was sind die 9 grundlegenden Prinzipien des RE?
- Wertorientierung
- Stakeholder
- Gemeinsames Verständnis
- Kontext
- Problem - Anforderung - Lösung
- Validierung
- Evolution
- Innovation
- Systematische und disziplinierte Arbeit
Was ist der Wert einer Anforderung?
Der Wert einer Anforderung ist gleich ihrem Nutzen abzüglich der
Kosten für das Ermitteln, Dokumentieren, Validieren und Verwalten
der Anforderung.
Was sind typische Beispiele für Stakeholder?
- Benutzer, der das zu entwickelnde System bedienen wird
- Kunde, dem das fertige System geliefert wird
- Auftraggeber, der für die Entwicklung und das auszuliefernde System zahlt
- Betreiber, der das System im Einsatz administriert
- Regulierungsbehörde, die einzuhaltende Normen, Standards und Gesetze verantwortet
Außerdem:
* Projektleitung/ -management
* Produktion
* Produktmanagement, Vertrieb
* Einkauf
* Qualitäts-/Prozessabteilung, Security-/Safety-Beauftragte
* Domänenexperte
* Architekt (des betrachteten Systems oder des einzubettenden Systems)
Was sollte bei Stakeholdern noch berücksichtigt werden?
- **Identifikation und Einbeziehung **der richtige S zum richtigen Zeitpunkt ist zentrale Aufgabe des RE
- Berücksichtigung von Nutzern existierender Systeme
- ein Stakeholder kann mehrere Rollen haben
- **Auflösen von Konflikten und Widersprüchen **unterschiedlicher A der S
Welche **zwei Arten von gemeinsamen Verständnis **werden unterschieden?
- explizites gemeinsames Verständnis: Dokumentation (Glossare, Prototypen, Kosten-Nutzen Abschätzungen), Abnahme / Reflexion
- implizites gemeinsames Verständnis: wichtig wo kein explizites V. gebildet werden kann (agil), basiert auf gemeinsamen Wissen aller Beteiligten, durch intensiven Austausch
Was ist der Systemkontext?
Der Systemkontext ist der Teil der Umgebung eines Systems, der für
die Definition und das Verständnis der Anforderungen des zu
entwickelnden Systems relevant ist.
Warum ist der Systemkontext relevant?
- essentiell für Definition der Systemanforderungen
- (Domänen)annahmen müssen gelten, damit das System Anforderungen erfüllen kann
- Änderungen im Kontext und deren Auswirkungen müssen identifiziert werden
Was ist die Systemgrenze?
Die **Systemgrenze separiert das geplante System von seinem Kontext.
Wie Systemgrenze bestimmen?
- innerhalb der Systemgrenze: veränderbar
- außerhalb der Systemgrenze: nicht veränderbar
Was soll im Zuge der korrekten Systemabgrenzung für jede Anforderung überprüft werden?
Prüfen für jede Anforderung:
* bezieht sich die gesamte Anforderung aus das System oder werden Teile der Anforderung durch vorgegebene Kontextaspaket erfüllt
* wird die Anforderung unnötig durch die aktuelle Systemabgrenzung eingschränkt? ( werden Dinge dem Konext zugeordnet, die eigentlich gestaltbar sein sollten)
Was ist der Umfang/ Scope (einer Systementwicklung??
Der Umfang (Scope) einer Systementwicklung beinhaltet alle Dinge,
die während der Entwicklung eines Systems gestaltbar sind.
Was sind die zwei Möglichkeiten, mit dem Scope umzugehen?
- zusätzlich zur Systemgrenze noch eine Scopegrenze definieren und verwalten
- Systemgrenze nutzen als Festlegung des Systemumfangs, Scopegrenze entfällt (nicht empfohlen)
Warum kann sich die Systemgrenze ändern und was ist dabei Aufgabe des RE?
Veränderung der Systemgrenze ist Normalfall
* Abgrenzung wird zu Beginn nur rudimentär verstanden
* neue Informationen über System und Kontextaspekte können Systemgrenze verschieben
Aufgabe RE:
* kontinuierliche Überprüfung und Anpassung der Systemgrenze ist zentrale Aufgabe
* bei jeder Anpassung müssen die Auswirkungen auf die Anforderungen überprüft werden
Wie wird ein Problem definiert?
Ein Problem ist eine Schwierigkeit, offene Frage oder ein unerwünschter
Zustand, die eine Untersuchung, genauere Beachtung oder eine
Lösung benötigen
Wie funktioniert die Problem-Anfoderungs-Lösungs-Kette?
- Problem als Ausgangspunkt für eine Entwicklung / Anpassung eines Systems
- erster Schritt: Betrachtung der Anforderungen
- Realisierung der Anforderungen durch ein soziotechnisches System
- aber Reihenfolge der Kette in der Praxis nicht immer linear:
*** Innovationen **bedingen zusätzliche Anforderungen - Anforderungen können auch als Lösung verstanden werden
- Problem, Anforderung, Lösung sind eng miteinander verflochten
- aber RE sollte versuchen diese zu trennen um Entwicklung nicht unnötig einzuschränken und Anforderungen reflektieren
Was wird bei der Validierung von Anforderungen überprüft?
- entspricht die A. tatsächlich den Bedürfnissen der S. bzw. kann sie auf eine **andere A.quelle **zurückgeführt werden?
- ist die A. ausreichend detailliert dokumentiert?
- sind sich die S. einig über die A. oder existieren Konflikte?
- sind Annahmen über den Kontext des Systems korrekt und gültig während des Betriebs des Systems?
Gründe für Änderungen von Anforderungen
- Sich ändernde Wünsche, Bedürfnisse, Ideen und Prioritäten von
Stakeholdern - Änderung von Geschäftsprozessen, die das System betreffen
- Verfügbarkeit von neuen Produkten und Lösungen von Wettbewerbern am Markt
- Technologische Veränderungen und Neuerungen
- Änderungen von Gesetzen, Vorschriften und Rahmenbedingungen
- **Feedback **von Stakeholdern (z.B. bei der Validierung oder Abnahme)
- Aufdecken von Fehlern oder Widersprüchen in bestehenden Anforderungen
- Feedback von aktuellen Systemnutzern beispielsweise Fehlermeldungen oder neue Bedürfnisse
Änderungen von Anforderungen sind Normalfall. welche zwei widersprüchlichen Ziele sollte ein RE dabei erreichen?
- Zulassen, dass sich Anforderungen ändern können (Nichtanpassungen würd ezu Problemen führen)
- A. möglichst stabil halten. Änderungen sind häufig teuer
Welche zwei Arten und Innovationen gibt es?
- inkrementell: bestehendes Produkt wird stetig verbessert (Effizienz, Kosten, neue Funktionalitäten)
- disruptiv: bekannte Technologien oder Produkte werden von neuen vollatändig abgelöst
Systematische und disziplinierte Arbeit - was ist dabei zu berücksichtigen?
- keine one fits all Lösung
- Situative Auswahl der auszuführenden Aktivitäten
- auf Erfahrungen aus vergleichbaren Projekten zurückgreifen
- Systematisches Vorgehen auch bei agilen Projekten
Was sind mögliche Typen von Aspekten im Systemkontext?
- Personen (Stakeholder oder Stakeholder-Gruppen)
- Systeme im Betrieb (andere technische Systeme oder Hardware)
- Alt-/Vorgängersysteme
- Prozesse (technisch oder physikalisch, Geschäftsprozesse)
- Ereignisse (technisch oder physikalisch) Dokumente (z.B. Gesetze, Standards, Systemdokumentationen
Was sind die Konsequenzen fehlerhafter oder unvollständiger Kontextberücksichtigung?
- Folge: unvollständige Anforderungen
- –> System arbeitet auf Grundlager unvollständiger / fehlerhafter Annahmen
- häufig Ursache für Systemversagen bei Betrieb (Fehler bleiben bei Überprüfung unentdeckt)
Wie hängen Systemkontext und Anforderungskontext zusammen?
- Ursprung der Anforderungen liegt im Systemkontext
- Anforderung ist als für spezifischen Kontext definiert
- je vollständiger der Kontext, umso geringer die Wahrscheinlichkeit für eine falsche Interpretation
Zwischen **welchen zwei Abgrenzungsprozesse **zur Abgrenzung des Systemkontexts wird unterschieden?
- Systemabgrenzung: welche Aspekte werden durch das System abgedeckt und welche Aspekte sind Teil der Umgebung
- Kontextabgrenzung: Grenze des Kontexts zur irrelevanten Umgebung, welche Aspekte haben eine Beziehung zu dem System
Systemgrenze und Kontextgrenze bestimmen den Systemkontext
