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
  • die Anforderungen an ein IT-System aus natürlich-sprachlichen, impliziten sowie potentiell unvollständigen und widersprüchlichen Informationen ableiten,
  • diese strukturiert, vollständig und widerspruchsfrei beschreiben
  • sie für die Umsetzung priorisieren,
  • und in geschlossener Form in einem Lastenheft dokumentieren, 
indem ich
  1. die jeweils geeigneten Methoden zur Ermittlung, Dokumentation, Prüfung und Verwaltung von Anforderungen einsetze,
    1. mich dabei selbst über Methoden und ihre Eignung für bestimmte Einsatzfelder und Situationen informiere, 
    2. meine Kollegen und Mitarbeitenden in diesen Methoden anleiten kann 
  2. mich dazu innerhalb meines Teil- und Gesamtteams sowie mit dem Kunden unter den Bedingungen eines realen Projekts abstimme,
    1. dies im Lastenheft reflektiere, 
    2. und abschließend meine Stakeholder in einer kompakten Präsentation über die Ergebnisse meiner Arbeit informiere,
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:

  • Ansprechpartner für Feedback zur Veranstaltung, weitergehende Fragen / Anregungen / Wünsche, Rückfragen zu Inhalten
  • Erreichbar am besten via Discord, wenn es um Fragen von allgemeinem Interesse geht
  • bei persönlichen Anliegen am besten per Email (antwortet in der Regel innerhalb eines Tages, sonst bitte nochmal nachfragen)
  • für weitergehende Anliegen am besten eine Sprechstunde buchen: https://calendly.com/bente/termine (aber bitte probieren Sie erstmal, ob es auch via Discord oder Mail zu klären ist)
  • Wird von Fall zu Fall in der Veranstaltung unterstützen 
  • erreichbar am besten über den Discord, ersatzweise per Email
  • Sie dürfen gerne außerhalb "üblicher" Zeiten Fragen stellen, eine Antwort dauert dann unter Umständen nur etwas länger.

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. 

Für die Workshops nutzen wir immer denselben Zoom-Link: 

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). 

Weitere wichtige Materialien Links zur Veranstaltung (Zusammenfassung)

Zeitplan


DatumPhaseAgendaInhalte MethodentrainingsInhalte Fallstudie
1Fr, 16.4.,
13:00 - 16:00
abweichende Uhrzeit!

Motivation, Einführung, Orga


  • Motivation für AM
  • Ziele der Veranstaltung, Struktur, Fallstudie, Methodentrainings, Bewertung
  • Einteilung der Teilteams
2Fr, 30.4.,
12:00 - 17:00
abweichende Uhrzeit!

1) Ziele, Stakeholder, Systemkontext


  • Training: Stakeholder-Interviews
  • Brainstorming Stakeholder
  • Absprache und Koordination der Stakeholder-Interviews im Gesamtteam
3Fr, 07.05., 10:00 - 16:00

2a) Erhebungstechniken


  • 10:00 - 11:30 Trainings Ziele und Systemkontext
  • 11:30 - 12:00 Abstimmungen Interview-Fragebögen
  • 12:00 - 12:30 Einführung Divekit
  • 13:15 - 13:30 Vorstellung Lastenhefttool
  • 13:30 - 15:30 Trainings Erhebungstechniken und Kano
  • 15:30 - 16:00 Aufteilung Workshopteams
  • Ziele
  • Systemkontext
  • Erhebungstechniken
  • Kano-Faktoren
  • Stand der Stakeholder-Interviews
  • Diskussion der Workshops: Welche Zielgruppen, welche Methoden?
4Fr, 21.5., 10:00 - 16:00

2b)  Personas und Szenarien

3) Glossar



  • Personas
  • Szenarien
  • Umgang mit Glossar 
  • Stand / Ergebnisse der Workshops
5Fr, 28.5., 
10:00 - 16:00

4) Funktionale Anforderungen



  • Funktionale Anforderungen
  • Nichtfunktionale Anforderungen
  • Koordination der Erstellung von funktionalen und nichtfunktionalen Anforderungen im Gesamtteam
6Fr, 18.6., 
10:00 - 14:00
abweichende Uhrzeit! (endet früher)

3) Glossar

5) Nichtfunktionale Anforderungen


  • Übung zum Glossar
  • Übung zu nichtfunktionalen Anforderungen
  • Sammeln der Artefakte
7Fr, 25.6., 
10:00 - 16:00

6) Priorisierung und Konfliktlösung

7) Use Cases


  • Priorisierung
  • Konfliktlösung
  • Use Cases
  • Methodenfestlegung und Vorbereitung der Priorisierung mit Stakeholdern
  • Verteilung Use-Case-Erstellung
8Fr, 9.7.,
10:00 - 16:00

8) Qualitätssicherung

9) Agiles Backlog


  • Agiles Backlog
  • Qualitätssicherung
  • Verteilung User Stories
  • Verteilung der QS-Zuständigkeiten
9Fr, 16.7., 10:00 - 16:00Abschluss

  • Stand der Arbeiten

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: 

  1. 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.  
  2. 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"): 

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-teamThemaTrainings-Inhalt
(durch verantwortliches Teilteam)
Für die Fallstudie zu erstellenAufgabe(n) verantwortliches TeilteamAufgabe(n) alle anderen Teilteams

1)

Stakeholder, Ziele, System-kontext

2-3Stakeholder-Interviews
  • Interviews vorbereiten, führen, auswerten
  • Liste mit >10 Stakeholdern
  • >6 Interviews mit wichtigen Stakeholdern
  • Sponsoreninterview selbst machen
  • weitere Interviews koordinieren
  • je ein Interview führen
Ziele
  • Ziele aus Quellen ableiten und formulieren
  • 10 - 20 Ziele 
  • am besten hierarchisch gegliedert und priorisiert
  • Quellen verteilen
  • Erstellung von Zielen daraus koordinieren
  • erste Qualitätskontrolle
  • (Teilteam macht selbst auch mit)
  • aus zugewiesenen Quellen Ziele ableiten und dokumentieren
Systemkontext
  • Systemkontext aus Quellen recherchieren
  • umfassender Systemkontext
  • Quellen verteilen
  • Erstellung von Systemkontext daraus koordinieren
  • erste Qualitätskontrolle
  • (Teilteam macht selbst auch mit)
  • aus zugewiesenen Quellen Systemkontext ableiten und dokumentieren

2a)

Erhebungs-techniken

2Erhebungs-techniken
  • passende Erhebungstechniken auswählen
  • Ausgewählte Techniken einüben
  • 2-3 Workshops geplant, durchgeführt, dokumentiert
  • Ziele: Ermittlung von ... 
    • Szenarien
    • Kano-Faktoren
  • alle Teilnehmer*innen teilen sich so auf, dass es insgesamt 2-3 Workshops gibt
    • Kreativ- oder Beobachtungsworkshops
    • Befragungstechniken (aber keine Interviews mehr, die hatten wir in Phase 1)
    • Wenn es passt auch Dokumentenauswertung
Kano-Faktoren
  • Kano-Klassifikation verstehen
  • Faktoren finden und mit Hilfe von Kriterien prüfen
  • >30 Kano-Faktoren in einem "Rohformat" (noch nicht formalisiert)
  • Verteilung der Quellen (insb. Workshop-Protokolle)
  • Erstellung von rohen Kano-Faktoren daraus koordinieren
  • erste Qualitätskontrolle
  • (Teilteam macht selbst auch mit)
  • Auswertung von Quellen und Erstellen von Kano-Faktoren

2b)

Personas und Szenarien

2Personas
  • Personas erstellen
  • >10 Personas
  • Verteilung der Quellen (insb. Workshop-Protokolle)
  • Koordination: Wer macht welche Personas?
  • erste Qualitätskontrolle
  • (Teilteam macht selbst auch mit)
  • 2-3 Personas erstellen
Szenarien
  • Szenarien erstellen
  • >10 Szenarien
  • Verteilung der Quellen (insb. Workshop-Protokolle)
  • Koordination: Wer macht welche Szenarien?
  • erste Qualitätskontrolle
  • (Teilteam macht selbst auch mit)
  • 2-3 Szenarien erstellen

3) 

Fachliches Glossar

1Glossar
  • Wie findet und formuliert man Glossareinträge?
  • umfassendes Glossar 
  • Erfassen von wichtigen Begriffen
  • Koordination: Zuweisen von Glossareinträgen (z.B. "Round Robin" Verfahren, oder danach, wer z.B. ein Interview geführt hat oder ein Protokoll verfasst)
  • erste Qualitätskontrolle
  • (Teilteam macht selbst auch mit)
  • Erstellen von Glossareinträgen

4)

Funktionale Anfor-derungen

1-2Funktionale Anforderungen
  • Anforderungen aus Quellen ableiten und mit Schablone formulieren
  • Anforderungen auf "Antipatterns" prüfen
  • >40 funktionale Anforderungen
  • klassifiziert nach Kano
  • Quellen verteilen
  • Erstellung von funktionalen Anforderungen daraus koordinieren
  • erste Qualitätskontrolle
  • (Teilteam macht selbst auch mit)
  • Erstellen von funktionalen Anforderungen für zugewiesene Quellen

5)

Nicht-funktionale Anfor-derungen

1-2Nichtfunktionale Anforderungen
  • Typen von NFA
  • Anforderungen aus Quellen ableiten und mit Schablone formulieren
  • Anforderungen auf "Antipatterns" prüfen
  • >20 nichtfunktionale Anforderungen
  • Quellen verteilen
  • Erstellung von nichtfunktionalen Anforderungen daraus koordinieren
  • erste Qualitätskontrolle
  • (Teilteam macht selbst auch mit)
  • Erstellen von nichtfunktionalen Anforderungen für zugewiesene Quellen

6)

Priorisierung und Konflikt-lösung

1-2Priorisierung
  • passende Priorisierungs-Methode auswählen
  • Priorisierungs-Methode praktisch einüben
  • priorisierte Liste von Anforderungen (F und NF)
  • Priorisierungsworkshop organisieren und dokumentieren
  • am Priorisierungsworkshop teilnehmen
Konfliktlösung
  • Konflikttyp einordnen können (Subtext erkennen)
  • Konflikte dokumentiert (falls das in der vorliegenden Fallstudie relevant ist!)
  • ggfs. existierende Konflikte dokumentieren 
    (falls es in der vorliegenden Fallstudie welche gibt!)
-

7)

Use Cases

1-2Use Cases
  • Use-Case-Erstellung üben
  • Aktivitäts-diagramme üben
  • 8 - 15 Use Cases 
  • für top-priorisierte Anforderungen Use Cases definieren und zuordnen
  • erste Qualitätskontrolle
  • (Teilteam macht selbst auch mit)
  • Erstellen von 1-2 Use Cases, ggfs. mit Aktivitätsdiagrammen

8)

Qualitäts-sicherung

2-3Qualitätssicherung
  • Methoden der QS einüben
  • für alle Artefakte in der Fallstudie gibt es ein QS-Protokoll
  • Änderungen sind umgesetzt
  • Koordination "wer macht was"
  • (Teilteam macht selbst auch mit)
  • Koordination "Änderungsvorschläge sind umgesetzt"
  • Übernehmen eines angemessenes Teils der QS

9)

Agiles Backlog

1-2Agiles Backlog
  • Bestandteile agiles Backlog
  • User Stories formulieren, teilen, schätzen
  • >30 User Stories für ein erstes Sprint Backlog (Ziel: MVP)
  • Koordination "wer macht welche User Stories"
  • (Teilteam macht selbst auch mit)
  • erste Qualitätskontrolle
  • Schreiben von User Stories


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:


RolleNameTeilteam
1WMA, CIDEJann Intveen1
2WMA, CIDEFabian Krampe7 (selbst)
3Professor, TH Köln, F07René Wörzberger4
4Professorin, TH Köln, F10Monika Engelen9
5Professor, TH Köln, F10Olaf Mersmann2b (selbst)
6Professor, Hochschule BremerhavenOliver Radfelder8
7Professor, TH Köln, F10Mario Winter2a
8WMAAlex Dobrynin6 (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.