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?
Welche Techniken gibt es, um Anforderungen zu ermitteln, dokumentieren, gliedern, validieren und messbar zu machen? Welche Kriterien werden an gute fachgerechte und überprüfbare Anforderungen angelegt?
UML-Usecase-Diagramme lassen sich mit vielen Tools erstellen. Um sie aber als versionierbaren Code direkt in die Readme-Dateien des Repositories zu übernehmen führt kaum ein Weg an PlantUML vorbei.
Ein Bild sagt mehr als tausend Worte: Funktionale Anforderungen lassen sich im Kundengespräch oft am schnellsten mit einem Diagramm zeichnen. Ein paar Strichmännchen, ein paar Ellipsen, ein Rechteck – aber was bedeuten die Notationsmittel genau, und wo setzte ich sie sinnvollerweise ein?
Aus den Usecase-Diagrammen kennen wir den Begriff Anwendungsfall. Aber was steckt dahinter – und wo kann es uns behilflich sein?
Anforderungen kommen nicht vom Himmel gefallen. Viele Projekte scheitern daran, dass nie hinreichend definiert wurde, was eigentlich die Ziele sein sollen. Wie kann eine systematische Anforderungsanalyse aussehen?
