Kap2 Flashcards
Def Aufgabe, Aktivität, Praktiken
Eine Aufgabe ist ein kohärentes Stück Arbeit, das ausgeführt werden muss.(z.B. das Ermitteln von Anforderungen).
Eine Aktivität ist eine Handlung oder eine Reihe von Handlungen, die eine Person oder Gruppe ausführt, um eine Aufgabe zu erfüllen (z.B. die Identifizierung von Stakeholdern bei der Ermittlung von Anforderungen).
Eine Praktik ist eine bewährte Methode zur Durchführung bestimmter Arten von Aufgaben oder Aktivitäten (z.B. die Verwendung von Interviews, um die Anforderungen der Stakeholder zu ermitteln).
Neun grundlegende Prinzipien des Requirements Engineering
1 Wertorientierung: Anforderungen sind Mittel zum Zweck, kein Selbstzweck
2 Stakeholder: Im RE geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen
3 Gemeinsames Verständnis: Erfolgreiche Systementwicklung ist ohne eine gemeinsame Basis nicht möglich
4 Kontext: Systeme können nicht isoliert verstanden werden
5 Problem - Anforderung - Lösung: Ein unausweichlich ineinandergreifendes Tripel
6 Validierung: Nicht-validierte Anforderungen sind nutzlos
7 Evolution: Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall
8 Innovation: Mehr vom Gleichen ist nicht genug
9 Systematische
Def Wert einer Anforderung
Nutzen abzüglich Kosten
Der Nutzen einer Anforderung ist der Grad, in dem sie zum Aufbau erfolgreicher Systeme und zur Verringerung des Risikos von Fehlschlägen und kostspieligen Nacharbeiten bei der Systementwicklung beiträgt.
Die Kosten für eine Anforderung entsprechen den Kosten für ihre Ermittlung, Validierung, Dokumentation und Verwaltung.
Vorteile durch RE
Die Vorteile von RE sind oft langfristige Vorteile, während die Kosten unmittelbar anfallen. Dies muss bei Beginn eines neuen Projekts berücksichtigt werden. Eine kurzfristige Kostensenkung durch geringere Ausgaben für RE hat einen Preis: Sie erhöht das Risiko teurer Nacharbeiten in späteren Projektphasen erheblich.
Wert des Requirements Engineering
kann als der kumulative Wert der spezifizierten Anforderungen betrachtet werden.
der wirtschaftliche Wert von RE ist meist ein indirekter:
Er spart Kosten bei der Implementierung und im Betrieb. RE als solches erzeugt nur Kosten.
Bewertung Kritikalität einer Anforderung
Zuallererst sollte die Kritikalität jeder Anforderung im Hinblick auf die Bedeutung der/des Stakeholder(s), die/der die Anforderung formulieren/formuliert (siehe Prinzip 2), und die Auswirkungen eines Fehlens der Anforderung bewertet werden.
y-Achse: Auswirkung einer fehlender Anforderung (niedrig, mittel, hoch)
x-Achse: Unbedeutend, wesentlich, kritisch
Einflussfaktoren einer Anforderung
Erforderlicher Aufwand zur Spezifizierung der Anforderung
Besonderheit der Anforderung (wie sehr sie zum Erfolg des Gesamtsystems beiträgt)
Grad des gemeinsamen Verständnisses zwischen Stakeholdern und Entwicklern und unter den Stakeholdern
Vorhandensein von Referenzsystemen (die als beispielhafte Spezifikation dienen können)
Länge des Feedback-Zyklus (die Zeit zwischen dem Spezifizieren einer falschen Anforderung und dem Erkennen des Fehlers)
Art der Kunden-Lieferanten-Beziehung
Einhaltung gesetzlicher Vorschriften
Faustregel zur Entscheidung wie viel RE:
Der optimale zu investierenden RE-Umfang hängt von der konkreten Situation ab und wird von vielen Einflussfaktoren bestimmt.
Der Aufwand, der in RE investiert wird, sollte umgekehrt proportional zu dem Risiko sein, das Sie bereit sind einzugehen.
Kernziele von RE
Die Kernziele von RE sind das Verständnis der Wünsche und Bedürfnisse der Stakeholder und die Minimierung des Risikos, ein System zu liefern, das diesen Wünschen und Bedürfnissen nicht gerecht wird;
Klassen von Stakeholdern
Kritisch: Die Nichtberücksichtigung dieser Stakeholder führt zu schwerwiegenden Problemen und lässt das System wahrscheinlich scheitern oder unbrauchbar werden.
Schwerwiegend: Die Nichtberücksichtigung dieser Stakeholder wird sich negativ auf den Erfolg des Systems auswirken, es aber nicht zum Scheitern bringen.
Geringfügig: Die Nichtberücksichtigung dieser Stakeholder wird keinen oder nur einen geringen Einfluss auf den Erfolg des Systems haben.
Die Einbeziehung der richtigen Personen in die entsprechenden Stakeholder-Rollen ist für erfolgreiches RE von entscheidender Bedeutung. Nur Endbenutzer und Kunden zu berücksichtigen, reicht nicht aus!
Def Explizites und implizites gemeinsames Verständnis
Explizites gemeinsames Verständnis wird durch sorgfältig ermittelte, dokumentierte und vereinbarte Anforderungen erreicht. Dies ist das primäre Ziel von RE in planbasierten Prozessen.
Implizites gemeinsames Verständnis basiert auf dem gemeinsamen Wissen über Bedürfnisse, Visionen, Kontext usw. In agilem RE, wenn die Anforderungen nicht vollständig schriftlich spezifiziert sind, ist das Vertrauen in ein gemeinsames implizites Verständnis entscheidend.
Rolle des REs: gemeinsames Verständnis schaffen, f´ördern und sichern.
Faktoren, die gemeinsames Verständnis fördern
Domänen-Wissen
Domänenspezifische Normen
Frühere erfolgreiche Zusammenarbeit
Vorhandensein von Referenzsystemen, die allen Beteiligten bekannt sind
Gemeinsame Kultur und Werte
Informiertes (nicht blindes!) gegenseitiges Vertrauen
Faktoren, die gemeinsames Verständnis behindern
Geografische Entfernung
Von gegenseitigem Misstrauen geprägte Lieferanten-Kunden-Beziehung
Outsourcing
Regulatorische Randbedingungen
Große und vielfältige Teams
Hohe Fluktuation unter den beteiligten Personen
Kontext: Systeme können nicht isoliert verstanden werden
Anforderungen sind nie isoliert zu betrachten. Sie beziehen sich auf Systeme, die in einen Kontext eingebettet sind.
Def Context
CONTEXT (IN RE): The part of a system’s environment beeing relevant for understanding the system and its requirements.
