Anforderungsmanagement (AM)
AM ist eine Pflichtveranstaltung im Informatik Master (Software Engineering). Diese Seite (mit den entsprechenden Unterseiten) wird fortlaufend aktualisiert. Es wäre also sinnvoll, wenn Sie die Seite bookmarken.
Aktuelles zu AM
Aktueller AM-Workshop am 18.6., Agenda steht hier.
Inhalte dieser Seite
Ziel der Veranstaltung
Anforderungsmanagement setzt zu Beginn des Software-Lebenszyklus an. Es geht um die Erarbeitung von möglichst präzisen, aber immer noch natürlichsprachlichen Spezifikationen für ein Softwaresystem, plus deren nachhaltige und dauerhafte Pflege. Der Fokus liegt dabei darauf, eine Brücke zwischen Fachseite und IT zu schaffen. Ein Anforderungsdokument muss von beiden Seiten gut zu verstehen sein, und dazu so präzise, dass Entwicklungsteams auf der Basis coden können.
Folgendes Learning Outcome liegt der Veranstaltung zugrunde - das sollten Sie am Ende können, wenn Sie für sich das Beste aus der Veranstaltung herausholen.
| Als | Anforderungsmanager*in oder Business Analyst*in mit Master-Abschluss |
|---|---|
| kann ich |
|
| indem ich |
|
| so dass ich | ein externes Implementierungsteam bei der Umsetzung in ein IT-System damit anleiten kann. |
Organisation der Veranstaltung
Wie Sie dem Stundenplan entnehmen können, sind für AM Dienstags und Freitags Zeitschlitze vorgesehen. Nutzen werde ich nur die Freitage, in der folgenden Form:
- Klassische Vorlesungen wird es nicht geben. Stattdessen wird es ganztägige Workshops geben. "Ganztägig" bedeutet hier im Allgemeinen 10:00 - 16:00 mit einer Mittagspause. Nicht jeder Freitag ist belegt, siehe Zeitplan unten.
- An diesen Workshoptagen wird es Methodentrainings geben (die Sie selbst für Ihre Kommilitonen durchführen, unter meiner Anleitung), Inhaltsimpulse und Arbeit an einer Fallstudie.
Team
Das ist das Beratungsteam für AM:
| |
|
Beratung vorzugsweise via Discord
Als sehr effektive Plattform zur Beratung und Diskussion hat sich bei uns Discord herausgestellt. Sie können daher dem ArchiLab-Discord-Server beitreten: https://discord.gg/YYNYb5whU8. Wählen Sie dann "AM" als Rolle, und Sie sehen die Channels für diese Veranstaltung.
Wer Discord nicht nutzen will, kann das mich auch direkt per Mail kontaktieren.
Zoom-Link
Für die Workshops nutzen wir immer denselben Zoom-Link:
- https://th-koeln.zoom.us/j/84227227657?pwd=bFpiNmdqMWdXa3c3QTNTd3Q1L3hpUT09
- Meeting ID: 842 2722 7657
- Passcode: am
Online-Lastenheft
Das Lastenheft wird in einem speziell dafür entwickelten Online-Format dokumentiert, basierend auf Git, Markdown und statischer Content-Generierung via Jekyll (Github Pages).
- Hier ist das entsprechende Repo: https://github.com/divekit/divekit-roadmap/
- Unter diesem Link ist das Lastenheft erreichbar: https://divekit.github.io/divekit-roadmap/
Weitere wichtige Materialien Links zur Veranstaltung (Zusammenfassung)
- ILIAS-Kurs
- Literaturliste, Passwort liegt hier auf ILIAS
- Anforderungsmanagement-Referenz mit Zusammenfassung aller relevanter Methoden
Zeitplan
| Datum | Phase | Agenda | Inhalte Methodentrainings | Inhalte Fallstudie | |
|---|---|---|---|---|---|
| 1 | Fr, 16.4., 13:00 - 16:00 abweichende Uhrzeit! | Motivation, Einführung, Orga |
| ||
| 2 | Fr, 30.4., 12:00 - 17:00 abweichende Uhrzeit! | 1) Ziele, Stakeholder, Systemkontext |
|
| |
| 3 | Fr, 07.05., 10:00 - 16:00 | 2a) Erhebungstechniken |
|
|
|
| 4 | Fr, 21.5., 10:00 - 16:00 | 2b) Personas und Szenarien 3) Glossar |
|
| |
| 5 | Fr, 28.5., 10:00 - 16:00 | 4) Funktionale Anforderungen |
|
| |
| 6 | Fr, 18.6., 10:00 - 14:00 abweichende Uhrzeit! (endet früher) | 3) Glossar 5) Nichtfunktionale Anforderungen |
|
| |
| 7 | Fr, 25.6., 10:00 - 16:00 | 6) Priorisierung und Konfliktlösung 7) Use Cases |
|
| |
| 8 | Fr, 9.7., 10:00 - 16:00 | 8) Qualitätssicherung 9) Agiles Backlog |
|
| |
| 9 | Fr, 16.7., 10:00 - 16:00 | Abschluss |
| ||
Methodentrainings
Vorgehensmodell
Das Vorgehensmodell für AM wurde an der TH Köln aus der Literatur und aus Praxiserfahrungen entwickelt. Sie können die untenstehende Abbildung auch hier als PDF herunterladen. In der Veranstaltung werden wird uns an diesem Vorgehensmodell orientieren und insbesondere die Methodentrainings darauf ausrichten.
Aufteilung in Teilteams
Jede Phase des Vorgehensmodells wird von einem Teilteam (1-3 Mitglieder, siehe Tabelle) betreut. Teilteams bilden sich selbst durch Einschreibung in eine der Gruppen auf ILIAS. Die Teilteams haben zwei wesentliche Verantwortlichkeiten:
- Sich zu Experten machen: Einarbeitung in die Methoden "ihrer" Phase und Konzeption von Übungen, so dass sie Methodentrainings für die gesamte Gruppe durchführen können.
- Eine Phase der Fallstudie betreuen: Jedes Teilteam hat für "seine" Phase der Fallstudie die organisatorische Verantwortung. Die Arbeit wird jeweils von allen gemacht, das Teilteam organisiert.
Dabei gibt es für die Teilteams folgende Hilfestellungen (siehe auch oben unter "Materialien zur Veranstaltung"):
- Literaturliste
- Anforderungsmanagement-Referenz mit Zusammenfassung aller relevanter Methoden
- Online-Lastenheft mit Git- und Markdown-basiertem Lastenheft-Tool (Link folgt)
Zuständigkeiten
In der nachfolgenden Tabelle sind die benötigten Trainings und die Artefakte für die Fallstudie (mit Verantwortlichkeiten) detailliert beschrieben.
| Teilteam | # pro Teil-team | Thema | Trainings-Inhalt (durch verantwortliches Teilteam) | Für die Fallstudie zu erstellen | Aufgabe(n) verantwortliches Teilteam | Aufgabe(n) alle anderen Teilteams |
|---|---|---|---|---|---|---|
1) Stakeholder, Ziele, System-kontext | 2-3 | Stakeholder-Interviews |
|
|
|
|
| Ziele |
|
|
|
| ||
| Systemkontext |
|
|
|
| ||
2a) Erhebungs-techniken | 2 | Erhebungs-techniken |
|
|
| |
| Kano-Faktoren |
|
|
|
| ||
2b) Personas und Szenarien | 2 | Personas |
|
|
|
|
| Szenarien |
|
|
|
| ||
3) Fachliches Glossar | 1 | Glossar |
|
|
|
|
4) Funktionale Anfor-derungen | 1-2 | Funktionale Anforderungen |
|
|
|
|
5) Nicht-funktionale Anfor-derungen | 1-2 | Nichtfunktionale Anforderungen |
|
|
|
|
6) Priorisierung und Konflikt-lösung | 1-2 | Priorisierung |
|
|
|
|
| Konfliktlösung |
|
|
| - | ||
7) Use Cases | 1-2 | Use Cases |
|
|
|
|
8) Qualitäts-sicherung | 2-3 | Qualitätssicherung |
|
|
|
|
9) Agiles Backlog | 1-2 | Agiles Backlog |
|
|
|
|
Fallstudie
Als Fallstudie werden wir ein Lastenheft für die Weiterentwicklung von Divekit erstellen.
Stakeholder
Die folgenden Stakeholder haben sich für ein Interview bereit erklärt:
| Rolle | Name | Teilteam | |
|---|---|---|---|
| 1 | WMA, CIDE | Jann Intveen | 1 |
| 2 | WMA, CIDE | Fabian Krampe | 7 (selbst) |
| 3 | Professor, TH Köln, F07 | René Wörzberger | 4 |
| 4 | Professorin, TH Köln, F10 | Monika Engelen | 9 |
| 5 | Professor, TH Köln, F10 | Olaf Mersmann | 2b (selbst) |
| 6 | Professor, Hochschule Bremerhaven | Oliver Radfelder | 8 |
| 7 | Professor, TH Köln, F10 | Mario Winter | 2a |
| 8 | WMA | Alex Dobrynin | 6 (selbst) |
Kreativ-Workshops
Es gibt ein QQ2-Projekt für aktuelle Teilnehmer*innen von ST2, die als Studierende gerade ein Divekit-basiertes Praktikum machen (und dann eine Divekit-basierte Klausur schreiben werden).
Online-Lastenheft
Das Lastenheft wird in Markdown auf Github erstellt. Hierzu ist eine Plattform gerade in der Vorbereitung; wird bis Mitte Mai verfügbar sein. Wir (Fabian Krampe und Stefan Bente) werden das Stück für Stück gemäß der Fortschritte in der Fallstudie entwickeln.
Bewertung der Veranstaltung
Beide Bestandteile der "indem ich ..." Klausel des Learning Outcomes werden explizit durch Veranstaltungsteile (1. Methodentrainings, 2. Fallstudie) abgedeckt und auch entsprechend benotet. Hier ist das detaillierte Bewertungsschema.