Diese Diashow benötigt JavaScript.

Wer immer schon wissen wollte, wie es denn ist, wenn sich das Kernteam trifft, dem gibt diese Dokumentation detaillierten Aufschluss.

In klassischen Wasserfall-ähnlichen Vorgehensmodellen fokussiert sich Requirements Management auf die Erstellung und Verwaltung einer funktional vollständigen, fehlerfreien Anforderungsdokumentation. Das Gebiet hat sowohl in der Forschung als auch der Praxis weit verbreitete Methoden (Use Cases, Objektmodelle) hervorgebracht. Der Analytiker spielt eine zentrale gestaltende Rolle in der Transformation unstrukturierter Anforderungen in strukturierte Spezifikationen.

Agile Vorgehensmodelle ändern das Feld des Requirements Management radikal – die schriftliche Spezifikation tritt in den Hintergrund, möglichst direkte mündliche Kommunikation zwischen Fachbereich (z.B. „Product Owner“) und Programmierern wird zu einem zentralen Element. Verfolgt man die vielen Diskussionen der immer größer werdenden Scrum-Community, kann man leicht den Eindruck gewinnen, dass die Rolle des Analytikers obsolete wird und schriftliche Dokumentation eher ein lästiges Beiwerk als ein wertvolles Asset ist.

Auf der größten deutschsprachigen Konferenz „Requirement Days“ war 2010 eine gewisse Verunsicherung der Requirements Community spürbar. Fragen wie

• Sind all die erprobten Methoden wie z.B. Use Cases obsolet?
• Welche Bedeutung haben Geschäftsobjektmodelle in SCRUM?
• Zu welchem Zeitpunkt braucht man wieviele Requirements?
• Sollen sich Mitarbeiter weiterhin spezialisieren (z.B. Analytiker/Programmierer/Tester) oder suchen Firmen nunmehr Generalisten die alles können?
• Wieviel schriftliche Spezifikation braucht ein Scrum Projekt?
• Rolle Product Owner in Fachbereich/IT Bereich?
• Kulturelle/Soziologische Aspekte an der Schnittstelle Fachbereich/IT

konnten auch von den Keynote Referenten nicht in der Tiefe beantwortet werden.