Blog
Warum KI mir beibringt grau zu mögen
KI ist weiterhin ein leuchtender Stern am Technologie-Himmel. Auch wenn die konkrete Weiterentwicklung noch unklar ist, hat sich unser Requirements Engineer Andreas Gahr mit dem heutigen Zustand befasst und einige Anwendungsmöglichkeiten identifiziert.
Gute Übersicht für alle Beteiligten
Stehen ein Moderator und vier Stakeholder vor einer Leinwand. Sagt der eine: „So und jetzt machen wir mal alles sichtbar.“ Klingt wie ein Witz? Ist es aber nicht. Denn Canvas kann das!
Zwei Zeilen als Wegweiser, Leitplanken und Rettungsanker
Das Anforderungsmanagement ist in Mitten einer Projektumsetzung oft damit konfrontiert das Ziel nicht aus den Augen zu verlieren. Der Elevator Pitch ist eine gute Methode dafür.
Dokumentation zur rechten Zeit
Effiziente und zeitnahe Dokumentation bei stabilem Zustand
Schaffe Werte, vermeide Verschwendung
Schlanke Dokumentation in agilem Umfeld
Acceptance Test Driven Development
Im vorherigen Beitrag erfuhren wir, welche Schwierigkeiten bei der Formulierung von Anforderungen auftreten und lernten ein paar einfache Regeln kennen, um zu einer sprachlich und somit auch inhaltlich verständlichen Spezifikation zu gelangen.
Wie muss eine „gute“ Dokumentation formuliert werden?
In diesem Beitrag möchte ich zunächst näher auf das Formulieren von Anforderungen eingehen. Wir setzen die Serie der Fallen fort mit „Falle 5“.
Falle 4: Unklare Fachbegriffe und Best Practices
Falle 4: Unklare Fachbegriffe
In jedem Unternehmen, Projekt, Fachabteilung gibt es zahlreiche Fachbegriffe und Redewendungen, die eigentlich nur dem jeweiligen Personenkreis geläufig sind.
Falle 2: Faule Kompromisse und Falle 3: Designfehler bei Geschäftsmodellen
Im 2. Artikel meiner Reihe stelle ich Falle 2: Faule Kompromisse sowie Falle 3: Designfehler bei Geschäftsmodellen vor. Thematisch passt der Aspekt der „Mehrdeutigkeiten in Anforderungsdokumenten” gut den Kontext der beiden „Fallen”, sodass ich auch dieses Thema in diesem Artikel aufgreife.
Sieben Fallen, die der Requirements Engineer kennen und meiden sollte
In den kommenden Artikeln möchte ich sieben Fallen vorstellen, die ein Requirements Engineer (RE) kennen und vor allem meiden sollte.