Lernkarten

Karten 108 Karten
Lernende 10 Lernende
Sprache Deutsch
Stufe Andere
Erstellt / Aktualisiert 05.04.2021 / 10.03.2022
Lizenzierung Keine Angabe
Weblink
Einbinden
0 Exakte Antworten 108 Text Antworten 0 Multiple Choice Antworten
Fenster schliessen

LZ 2.2.1 Scrum als ein Beispiel kennen: (Rollen, Prozesse, Artefakte und deren) Relevanz für das Requirements Engineering

EU 2.2 Scrum (plus bewährte Verfahren) als Beispiel (K1)

Im Scrum werden keine Requirements-Engineering-Techniken eingesetzt. Trotzdem ist es für RE relevant. Denn im «Product Backlog» werden die aufgeführten Items resp. Anforderungen gebündelt.

Das Backlog sollte „DEEP" (Detailed appropriately, Estimated, Emergent, Prioritized, d. h. angemessen detailliert, geschätzt, dynamisch, priorisiert) sein.

Alternativ gilt die «INVEST»-Regel:

I: „Independent of each other" - unabhängig voneinander

N: „Negotiable" - verhandelbar

V: „Valuable" - wertvoll, nützlich

E: „Estimable" - schätzbar

S: „Small enough to fit into one sprint" - klein genug für einen Sprint

T: „Testable" - testbar

Im RE werden ähnliche Kriterien für gute Anforderungen genannt:

  • abgestimmt
  • Eindeutig
  • Notwendig
  • Konsistent
  • Prüfbar
  • Realisierbar
  • Verfolgbar
  • Vollständig
  • Verständlich
Fenster schliessen

LZ 2.2.2 Verantwortlichkeiten eines Scrum Product Owner kennen

EU 2.3 Unterschiede und Gemeinsamkeiten von Requirements Engineers und Product Ownern (K1)

Die wichtigsten Verantwortlichkeiten eines Product Owners sind:

  • Sicherstellen, dass das Entwicklungsteam konstanten betriebswirtschaftlichen Wert liefert: Das bedeutet, dass der Product Owner die längerfristige Vision für das Produkt und kurzfristige Bedürfnisse ins Gleichgewicht bringen muss, und er das Product Backlog aus betriebswirtschaftlicher Sicht priorisieren und die Ergebnisse des Entwicklungsteams zusammen mit den Stakeholdern am Ende jedes Sprints prüfen muss.
  • Managen aller Stakeholder: Der Product Owner ist dafür verantwortlich, konsistente Anforderungen an das Team weiterzuleiten. Er muss Anforderungen aller Stakeholder erfassen und sicherstellen, dass sich die Anforderungen nicht widersprechen. Es muss etwaige Meinungsverschiedenheiten zwischen Stakeholdern lösen, um das Entwicklungsteam davon zu entlasten.
  • Kontinuierliche Versorgung des Entwicklungsteams mit den hochrangigen Einträgen aus dem Backlog: Die Granularität dieser Anforderungen muss klein genug sein, damit sie sich für einen Sprint eignet. Für alle Fragen, die nach dem Sprint-Planungsmeeting entstehen, muss der Product Owner zur zügigen Klärung zur Verfügung stehen.
Fenster schliessen

LZ 2.2.3 Konzept des Product Backlog mit Epics und User-Storys kennen

EU 2.2 Scrum (plus bewährte Verfahren) als Beispiel (K1) 

Im «Product Backlog» werden die aufgeführten Items resp. Anforderungen gebündelt.

  • Je nach Granularität werden die Anforderungen in «Epics», «Features» und «User-Storys» zerlegt.  
  • Es wird unterschieden zwischen funktionalen Anforderungen (Fähigkeit), Qualitätsanforderungen (Verhalten) und Randbedingungen (Umgebung)
  • Und nach Anforderungsthemen gruppiert.

Innerhalb des Sprints gibt es das Backlog Refinement bei dem Anforderungen besprochen und verfeinert werden.

Mit der «Definition of Done» (DoD) entwickelt das Team ein gemeinsames Verständnis davon, wann ein Product Backlog Item vollständig und bereit für die Produktionsfreigabe ist.

Fenster schliessen

LZ 2.3.1 Unterschied zwischen einem klassischen Requirements Engineer und einem Scrum Product Owner kennen

EU 2.3 Unterschiede und Gemeinsamkeiten von Requirements Engineers und Product Ownern (K1)

Vergleicht man diese beiden Rollen, so zeigt sich, dass sowohl der Requirements Engineer als auch der Product Owner (gemeinsam mit allen Stakeholdern) die zentralen Aufgaben Ermitteln, Dokumentieren, Validieren und Managen von Anforderungen durchführen muss.

Die Notationen und Werkzeuge, die dabei zum Einsatz kommen, sind in agilen Entwicklungsprozessen jedoch in der Regel weniger formell:

  • Story-Cards anstelle von Anforderungsdokumenten
  • mehr Gespräche und weniger Schreibarbeit
  • stärkere Betonung von aktuellen Statusanforderungen, weniger Betonung auf Versionierung und Verlauf

Es ist zwar wichtig, eine Gesamtverantwortung für Anforderungen von hoher Qualität kontinuierlich aufrechtzuerhalten, dabei ist die Rolle des Product Owners breiter gefächert als die eines herkömmlichen Requirements Engineers: Ein Product Owner ist für den Erfolg des Produkts insgesamt, das fortwährende Einholen von Feedback von den Stakeholdern sowie für das entsprechende Aktualisieren und Priorisieren des Backlogs verantwortlich.

Fenster schliessen

LZ 2.4.1 Gute Gründe dafür kennen, weshalb das Requirements Engineering Teil eines kontinuierlichen Prozesses sein sollte

EU 2.4 Requirements Engineering als kontinuierlicher Prozess (K1) 

Gute Gründe dafür kennen, weshalb das Requirements Engineering Teil eines kontinuierlichen Prozesses sein sollte:

  • Das Requirements Engineering in agilen Entwicklungsprozessen ist keine klar abgegrenzte Phase während der Entwicklung, sondern eine iterative und laufende Aktivität.
  • Die Ermittlung und Analyse sämtlicher Anforderungen, bevor das Design und die Implementierung beginnen können, ist nicht das Ziel; Anforderungen und Produkte werden gleichermaßen iterativ und inkrementell erstellt.

Das Requirements Engineering ist daher eine fortlaufende Aktivität, die so lange dauert wie die gesamte Entwicklung des Produkts.

  • Gleichwohl hat dieser Prozess gut definierte Zwischenergebnisse: die vorausgesagten Anforderungen, welche den grössten betriebswirtschaftlichen Wert versprechen, sollten „bereit für die Implementierung" sein (Definition of Ready).
  • Andere, aus betriebswirtschaftlicher Perspektive weniger dringende Anforderungen werden erst dann verfeinert, wenn die dringenden Anforderungen abgeschlossen sind.

Der „kontinuierliche Prozess" schließt einige wichtige Vorabaktivitäten nicht aus. Selbst wenn für Anforderungen jeweils rechtzeitig auf Basis des Need-to-Know Prinzips geklärt werden, so gibt es einige Aspekte, die dennoch frühzeitig im Projektlebenszyklus behandelt werden müssen. Als Beispiele seien das Definieren von Visionen oder Zielen, das Kennen der Stakeholder und das Erarbeiten des Produktumfangs genannt. Beginnt man die Implementierung ohne diese Aktivitäten, so erhöht sich das Risikolevel erheblich.

Fenster schliessen

LZ 2.5.1 Wertorientierte Entwicklung kennen (z.B. Priorisierungen von Anforderungen) 

EU 2.5 Wertorientierte Entwicklung (K1) 

Mit agilen Methoden wird das Ziel verfolgt, dem Endbenutzer kontinuierlich betriebswirtschaftlichen Wert zu liefern. Betriebswirtschaftlicher Wert lässt sich in finanzieller Hinsicht, in einem höheren Marktanteil oder in Bezug auf die Kundenzufriedenheit direkt ausdrücken.

Die Anforderungen, welche den größten betriebswirtschaftlichen Wert versprechen, sollten „bereit für die Implementierung" sein (Definition of Ready). Andere, aus betriebswirtschaftlicher Perspektive weniger dringende Anforderungen werde erst dann verfeinert, wenn die dringenden Anforderungen abgeschlossen sind.

Fenster schliessen

LZ 2.5.2 Wissen, dass Wert gleichbedeutend ist mit Risiko- UND Chancenmanagement

EU 2.5 Wertorientierte Entwicklung (K1) 

Eine andere Art von Wert ist die Risikoreduktion. Gute agile Ansätze versuchen, ein Gleichgewicht zwischen betriebswirtschaftlichem Wert und Risikominderung für die Iterationen herzustellen. Um die Anforderungen mit dem optimalen Wert zu ermitteln, streben agile Methoden häufig Minimum Viable Products (MVPs).

Fenster schliessen

LZ 2.5.3 Beispiele für Wert in gewinnorientierten und Non-Profit-Organisationen kennen

EU 2.5 Wertorientierte Entwicklung (K1) 

Der Ansatz dem Endbenutzer kontinuierlich betriebswirtschaftlichen Wert zu liefern, wird häufig in gewinnorientierten Organisationen verfolgt. Aber für Non-Profit-Organisation lässt sich der Wert nicht ganz so klar definieren. Für diese können Kennzahlen wie Nutzungsquoten oder der Zufriedenheitsindex für ein Produkt (d. h. Klickraten auf Websites oder Spenden für eine Non-Profit-Organisation) relevanter sein.