Eine umfangreiche Übungsaufgabe zu User Stories: einen englischen Fachtext auswerten, den Aufbau und die INVEST-Kriterien erläutern, User Stories aus einem Anwendungsfalldiagramm erstellen, fehlerhafte Stories verbessern, Akzeptanzkriterien formulieren, Aussagen zum Product Backlog prüfen und User Stories mit einem Pflichtenheft vergleichen.
User Stories beschreiben Anforderungen in einem Satz aus Sicht der Nutzenden: Wer möchte was, und wozu? Der Artikel zeigt die Satzschablone, wer Stories schreibt, wie Du sie mit den INVEST-Kriterien und Akzeptanzkriterien prüfbar machst, wie Du sie aus Anwendungsfällen ableitest, zu große Stories schneidest, welche Rolle sie im Product Backlog spielen und wie ein Team ihren Aufwand mit Planning Poker schätzt. Am Ende stehen die wichtigsten englischen Fachbegriffe für Aufgabentexte.
Vier Übungsaufgaben zu Stakeholdern und Projektumfeld: Einstieg mit einer Mitfahr-App (intern/extern, Stakeholder-Portfolio), die Digitalisierung von Lager und Werkstatt eines Fahrradherstellers mit fehlerhafter Stakeholderliste und Streit um Key User, die Planung eines Barcamps mit Projektumfeldanalyse, Bewertung geplanter Gegenmaßnahmen und Veränderungen im Stakeholder-Portfolio sowie die Einführung einer KI-gestützten Moderation in einer Freizeit-App mit Kommunikationsplan.
IT-Projekte scheitern selten an der Technik allein, sondern oft an Menschen und Rahmenbedingungen, die niemand rechtzeitig bedacht hat. Dieser Artikel zeigt, wie Du mit einer Projektumfeldanalyse technische, rechtliche, wirtschaftliche, organisatorische und personelle Einflüsse erfasst, die Umfeldanalyse von der Machbarkeitsanalyse abgrenzt, Stakeholder identifizierst und mit ihren Erwartungen, Befürchtungen und ihrem Einfluss bewertest, passende Maßnahmen ableitest und Konflikte und Widerstände so bearbeitest, dass das Projekt Akzeptanz findet.
Drei Übungsaufgaben zu funktionalen und nichtfunktionalen Anforderungen: Für eine Mitfahr-App wählst Du Ermittlungsmethoden, ergänzt einen Anforderungskatalog mit Akzeptanzkriterien und machst unpräzise Anforderungen prüfbar. Für eine Freizeit-App leitest Du aus einem Störungsprotokoll Anforderungen ab und berechnest Verfügbarkeit und zulässige Ausfallzeiten. Für die Geräteausleihe einer Schule erstellst Du einen Gesprächsleitfaden und beschreibst Schwachstellen und technische Anforderungen.
Viele Projekte scheitern an einer unzureichenden oder nicht fachgerechten Anforderungsanalyse. Diese Übungsaufgaben wiederholen die Techniken und Best Practices des Requirements Engineering: Projektumfeld und Stakeholder analysieren, Anforderungen ermitteln, tabellarisch dokumentieren, priorisieren und mit den INVEST-Kriterien prüfen.
Nicht alle Anforderungen sind gleich wichtig, nicht alle Anforderungen sind auf Anhieb gut formuliert/dokumentiert. Woran erkenne ich gute Anforderungen, woran erkenne ich wichtige Anforderungen? Und: Gibt es auch zu viel Spezifikation?
Es stehen die Wünsche der Stakeholder im Raum – und auch die Normen und Gesetze wollen als Anforderung dokumentiert werden. Welche unterschiedlichen Artefakte gibt es, in denen Anforderungen erfasst werden können, und wo eignen sie sich besonders?
Woher kommen Anforderungen, und mit welchen Techniken ermittelst Du sie systematisch? Der Artikel zeigt, wie Du Umfeld, Systemkontext und Stakeholder analysierst und welche Ermittlungstechnik – Interview, Fragebogen, Beobachtung, Workshop, Dokumentenanalyse oder Prototyp – zu welcher Situation passt.
Praktische Tipps, wie UML Anwendungsfalldiagramme mit Hilfe von PlantUML erstellt werden können. Ich versuche mich dabei näher an die UML-Spezifikation zu halten, als dies auf der PlantUML-Seite der Fall ist. Informationen zu UML-Anwendungsfalldiagrammen allgemein finden sich in einem gesonderten Use-Case-Diagramm-Artikel.
Mit UML-Anwendungsfall-Diagrammen können Übersichten erstellt werden, welchen Nutzen ein System den Benutzer*innen zur Verfügung stellt. Das einfache Diagramm bietet wenig Notationsmittel, mithilfe derer Beziehungen dargestellt werden: zwischen Nutzergruppen, zwischen Anwendungsfällen und von Nutzenden zu Anwendungsfällen. Dieser Artikel stellt diese UML-Notationen vor, zeigt, wie Du aus einem Anforderungstext Schritt für Schritt ein Diagramm entwickelst, und sammelt typische Fehler.
Anwendungsfälle stellen den Nutzen, den ein System für Benutzer*innen bereitstellt, in das Zentrum der Betrachtung. Mit ihnen können Anforderungen identifiziert und (tabellarisch oder als Diagramm) dokumentiert werden.
Viele Projekte scheitern daran, dass nie hinreichend definiert wurde, was eigentlich die Ziele sein sollen. Wie kann eine systematische Anforderungsanalyse aussehen? Der Artikel erklärt, was Anforderungen sind, wie Du funktionale und nichtfunktionale Anforderungen (Qualitätsanforderungen und Randbedingungen) sicher unterscheidest, wie Du sie mit Bezug zur Situation beschreibst und prüfbar formulierst und welche typischen Fehler Du dabei vermeiden solltest.
