- Requirements Engineering ist immer vorgelagert (upfront). Manche vertreten nach wie vor die Ansicht, dass Requirements Engineering stets als vorgelagerte Tätigkeit stattfinden muss, also die gesamte Spezifikationstätigkeiten am Beginn eines Projekts zu erfolgen hat. Tatsächlich findet RE aber unabhängig vom jeweiligen Vorgehensmodell und von den Phasen im Prozess ständig statt. Natürlich gibt es Schwerpunkte, aber Requirements Engineering ist in der Praxis ein integraler Bestandteil eines jeden Projekts – in allen Phasen vom Beginn bis zum Abschluss. RE ist grundsätzlich als Disziplin prozessunabhängig und kann sowohl im nicht agilen als auch im agilen Vorgehen gleichermaßen angewendet werden.
- Vorgelagert ist schlecht. Unabhängig vom gewählten Vorgehen ist es ratsam, die Anforderungen und Randbedingungen vorab durchzudenken. Das muss weder viel Zeit beanspruchen, noch die Erstellung umfangreicher Dokumente umfassen. Auch das Agile Manifest und die agilen Prinzipien sagen nicht, dass vorausschauendes Denken schlecht wäre. Verschiedene Praktiken aus dem agilen Umfeld unterstützen dies sogar, wie z.B. Story Maps, Prototyping oder Test Driven Development. So sind etwa auch spezifizierte Testfälle im Grunde
janichts anderes als eine sehr detaillierte Requirements-Spezifikation. - Requirements Engineering = Dokumente bzw. Dokumentation. Leider wird der Begriff Requirements Engineering oft ausschließlich mit dem Erstellen umfangreicher Anforderungsdokumente assoziiert. Doch diese Perspektive ist zu eng gefasst. Durch Aktivitäten des Requirements Engineerings, die hauptsächlich auf die Kommunikation mit den Kunden und das Schaffen von Wissen abzielen, können Dokumente als Ergebnis entstehen, müssen es jedoch nicht. Die Erstellung von Dokumenten ist nur dann sinnvoll, wenn sie für den weiteren Verlauf des Projekts von Nutzen sind.
- User Stories sind ausreichend für das RE im agilen Umfeld. Im agilen Umfeld sind User Stories zweifellos eine weit verbreitete Spezifikationstechnik. Allerdings ist es unzureichend, sich ausschließlich auf diese zu verlassen. Die Erstellung von User Stories deckt lediglich eine Ebene und Sichtweise ab. Um ein umfassendes Verständnis für die Perspektive der Kunden:innen zu entwickeln und folglich eine passende Systemarchitektur, Systemdesign und ein funktionales Produkt zu erstellen, müssen zusätzliche Abstraktions- und Beschreibungsebenen berücksichtigt werden (wie z.B. Kontext, Prozess-Sicht, nicht-funktionale Anforderungen usw.). Insbesondere gehen übergeordnete Zusammenhänge und die Prozessperspektive verloren, wenn man sich ausschließlich auf die Erstellung von User Stories konzentriert.
- Dokumente sind wertlos, nur Code hat bleibenden Wert. Früher wurden häufig umfangreiche und schwer verständliche Textdokumente erstellt. Dokumente erhielten dadurch generell ein negatives Image. Das bedeutet aber nicht, dass alle Spezifikationsdokumente wertlos sind oder immer nur in Textverarbeitungsprogrammen erstellt werden müssen. Dokumente, wie Anforderungsspezifikationen, Testdokumente, Risikoanalysen, Schulungsunterlagen sowie Architektur- und Designdokumente, sind für eine nachhaltige Softwareentwicklung unerlässlich, sofern sie zum richtigen Zeitpunkt und in angemessenem Umfang und Format erstellt werden oder in geeigneten integrierbaren Tools verwaltet werden.
- Anforderungen können nur durch lauffähige Software validiert werden. Obwohl im Agilen Manifest lauffähige Software über die Dokumentation priorisiert wird, bedeutet dies nicht, dass die Umsetzung der Anforderungen allein anhand der lauffähigen Software beurteilt werden kann. Es gibt verschiedene Methoden im Requirements Engineering, um die Anforderungen der Kunden:innen zu validieren, auch ohne lauffähige Software oder eine einzige Zeile Code. Dazu gehören beispielsweise Wireframes, Skizzen, Storyboards oder szenariobasierte Spezifikationen der Benutzeroberfläche und des Systemverhaltens.
