Als wir das Requirements-Engineering-Plakat veröffentlicht haben, lieferten wir einen ersten Kern zum Thema der Agilität mit und versprachen, dass weitere Kerne mit wertvollem Inhalt folgen werden. Damit würde das Plakat modular und flexibel anpassbar. Ganz nach den Bedürfnissen der einzelnen Betrachter.
In einer perfekten Welt sind alle Projekte von Anfang an richtig definiert und abgegrenzt, leicht geplant und jede Phase verläuft reibungslos. Wir alle wissen aber, dass Realität und Traum oft weit auseinander liegen!
Um der steigenden Komplexität der zu entwickelnden Produkte entgegen zu kommen, sind ein paar Experten auf einen Ansatz gekommen. Ja, Sie haben richtig geraten: Agilität!
Herzlich Willkommen zurück zu unserer Blog-Serie rund um unser Buch „Requirements-Engineering & -Management – Aus der Praxis von klassisch bis agil“. Im letzten Blogartikel wurden die Grundlagen für die Systemanalyse geschaffen, wie die Dokumentation von Geschäftsprozessen mit Hilfe der UML & weiteren Analysemitteln erfolgreich durchgeführt werden kann. Im heutigen Artikel widmen wir uns der modellbasierten Dokumentation von Systemanforderungen, also der Dokumentation von funktionalen Anforderungen an unser System mittels UML.
Und die Reise durch unser Requirements-Engineering und -Management Buch geht weiter. Heute machen wir einen kurzen Halt in der Welt des SOPHIST REgelwerks.
Ein häufiges Problem bei der Ermittlung von Anforderungen ist das Phänomen der Transformation, wobei die Realität durch den sprachlichen Ausdruck anders dargestellt wird.
„Wir wollten nicht nur jeden einzelnen Schritt perfekt machen, sondern auch noch den Gesamtablauf genau vorhersagen können.“
Um den Gesamtablauf Ihres Projekts vorhersagen zu können, ist die Definition eines Vorgehensmodells unabdingbar. Grundsätzlich wird zwischen schwer- und leichtgewichtigen Vorgehen unterschieden. Doch bevor wir nun näher auf die unterschiedlichen Ausprägungen von Vorgehen eingehen, stellt sich die Frage: Wozu sollte man ein Vorgehensmodell definieren?