Glaubt man einer Studie der Standish Group aus dem Jahre 2002, könnte man dies glauben. Dieser Studie zufolge werden 45% aller Features eines Produkts nie benutzt. Führen Sie sich die Bedeutung des Wortes „nie“ nochmals vor Augen: diese Features werden nicht gelegentlich, oder selten, oder nur von speziellen, kleinen Zielgruppen genutzt, sondern überhaupt gar nicht! Wozu dann all der Aufwand, all die Zeit, all das Geld während der Entwicklung?
Ziele und Nutzen des systematischen Umgangs mit Anforderungen
Kürzlich wurde ich wieder gefragt, wie sich der Aufwand von Requirements Engineering rechtfertigen lässt. Immer noch beobachte ich, dass die Tätigkeit des „systematischen Umgangs mit Anforderungen“, dies ist eine moderne Übersetzung des englischen Begriffs „Requirements Engineering and Management“, zu wenig Akzeptanz innerhalb der Unternehmen findet. Es werden verschiedenste Gegenargumente vorgetragen: Für das Projektmanagement ist es viel zu teuer, für die Entwickler und Fachabteilungen ist es „unmotivierter Mehraufwand“ oder „Overhead für Dokumentation“, für manche agile Teams ist es „alter Hut“ und für erfahrene, gewachsene Fachabteilungen ist es „nicht notwendig, das haben wir schon immer so, ohne Anforderungen, gemacht“.
Gewiss, der systematische Umgang mit Anforderungen kostet Zeit und Geld, und der Aufwand muss adäquat an die Struktur und die Gegebenheiten der Organisation, des zu entwickelnden Produktes oder Dienstleistung angepasst werden.
Die Anforderung lebt!
Ist das Requirement Engineering tot?
Den Begriff „Requirements Engineering“ verbinden viele mit schwergewichtigen, dokumentenorientierten Vorgehensweisen, mit denen man Riesenprojekte besonders in der Luft- und Raumfahrt durchführt. Es beschreibt eine Herangehensweise aus den alten Zeiten der trägen „Wasserfall“-Projekte. Das Wort „Engineering“ klingt dabei wie ein komplexes Konstrukt, eine aufwändige Maschinerie für Anforderungen, ein starres Gebilde, das viel Ressourcen verschlingt und sich, wenn überhaupt, nur träge und langsam bewegt.
Vertrauen ist gut, Kontrolle ist besser!?
Ist es in ihrem Unternehmen auch völlig normal geworden, dass jede scheinbar noch so unbedeutende Kleinigkeit ausgewertet und analysiert wird? Gibt es auch bei ihnen einen Mitarbeiter, der nichts anderes tut, als seine Kollegen zu überwachen? Diesen Trend hin zu immer mehr Kontrolle und Statistiken beobachte ich seit einiger Zeit mit wachsender Besorgnis – denn diese metrikgetriebene Entwicklung hat einen erheblichen Einfluss auf den Arbeitsalltag aller Entwicklungsbeteiligten. Lesen Sie hier, warum sich das titelgebende Sprichwort nicht immer bewahrheitet.
World Café Inspirationen – Lücken und Brücken im Requirements Engineering
„Wo sind die Lücken und Brücken im Requirements Engineering?“. 
Das war die Frage auf dem World Café der REConf® 2015 – mit inspirierenden Ergebnissen. Viele Themen dazu wurden von den Teilnehmern, über den Vormittag verteilt, an eine Pinnwand gehängt und am Abend auf dem World Café diskutiert. Hier eine Zusammenfassung der Ergebnisse:
Der Requirements Manager als Vorarbeiter für den Requirements Engineer
Eine einheitliche Abgrenzung zwischen den Begriffen Requirements Engineering und Requirements Management findet sich in der fachlichen Literatur nicht. Häufig wird Requirements Management als Teil des Requirements Engineering dargestellt, aber auch mal Requirements Engineering als Teil des Requirements Management. Als dritte Option werden Requirements Engineering und Requirements Management als nebeneinanderstehende Tätigkeiten betrachtet.
REConf 2015 – A never ending Erfolgsstory
Seit mehr als 10 Jahren veranstaltet die HOOD Group die größte Konferenz im deutschsprachigen Raum zum Thema Anforderungsmanagement – die REConf (Requirement Engineering Conference). Doch dieses Jahr verbuchte die REConf 2015 unter dem Motto „Bridging Gaps“ einen Rekord wie noch nie.
Mehr als 450 Teilnehmer besuchten die Konferenz vom 16.03. bis 19.03. und konnten sich Überblick über die aktuellsten Produkte und Dienstleistungen bei 11 Sponsoren und 20 Ausstellern verschaffen.
Lücken und Brücken im Requirements Engineering – GAPS and BRIDGES
Schon wieder Probleme mit den Zulieferern oder dem Lastenheft? Die Qualität des Produkts stimmt nicht? Die Entwicklung braucht zu lange? Die Produktpalette wird immer komplexer? Wir führen ja Requirements Engineering ein, aber …? Wo sollte ich ansetzen, wo ist speziell bei uns die Lücke im Entwicklungsprozess?
smartfacts – Analyse- & Designmodelle auf einen Blick
Entwicklungsprojekte sind heutzutage komplexer denn je. Planung und Konzeption eines Systems (Hardware als auch Software) kommen selten mit den „Standardwerkzeugen“ einer einfachen IT-Basisausstattung wie MS Office aus. Fachabteilungen setzen daher unterschiedliche Profitools für besondere Aufgabenbereiche ein, die ihnen die Arbeiten erleichtern und sie auch bei komplexen Aufgaben ideal unterstützen.
Kommunikation im Anforderungsmanagement
Wer ist für diese Anforderung verantwortlich? Was bedeutet dieses Attribut? Wer muss dieses Attribut setzen? Fragen im Rahmen des Requirements Engineerings, die Sie mit Sicherheit in Ihrem Unternehmen schon oft gehört haben. Doch wie lässt sich zügig eine Antwort finden?