Unsere diesjährige REConf®2017, die größte Konferenz zum Thema Requirements Engineering im deutschsprachigen Raum, fand vom 27. bis 31. März 2017 im Holiday Inn München City Center im Herzen von München statt. Wie jedes Jahr war die REConf® wieder sehr gut besucht. Neben interessanten Vorträgen und Workshops gab es für die Teilnehmer genügend Raum für Diskussionen und persönlichen Austausch mit anderen Teilnehmern, aber auch mit den Referenten.
Tischtennis oder Tennis sind in unserer Gesellschaft beliebte Spiele bzw. Disziplinen, an denen wir uns gerne messen und Spaß haben. Das Prinzip basiert darauf, dass jeder Spieler für sich seinen Schlag vorbereitet und ausführt (Ping). Der andere bekommt den Ball und reagiert in gleicher Weise wieder durch eine selbständige Vorbereitung und Ausführung des Gegenschlages (Pong).
In der Entwicklungsrealität haben wir dieses Prinzip in vielen Bereichen auch übernommen. Um dies näher zu beleuchten, zunächst ein Beispiel dazu.
Für die Strukturierung von Anforderungen hatte ich in dieser Blogserie schon die Kriterien und Techniken besprochen. Nach dem Blick auf die eher theoretischen Aspekte will ich mich heute einer konkreten Umsetzung widmen. Die Frage lautet: Wie gestaltet man die Gliederung von Anforderungen innerhalb einer Spezifikation?
Ich möchte Ihnen heute einen Einblick in die Themen Usability und User Experience (UX) geben und aufzeigen, dass die Parallelen zum Requirements Engineering (RE) größer sind, als man auf den ersten Blick annehmen würde! Außerdem wartet ein Gewinnspiel auf Sie!
…wahrscheinlich nicht sooooo cool, zumindest bei meiner Tochter, denn die verbindet „Anforderungen“ eher mit Aussagen wie „Räum den Tisch ab!“ und „Räum dein Zimmer auf!“.
Doch welchen Stellenwert hat Requirements Engineering und der Umgang mit Anforderungen heutzutage im Umfeld der Software-, Produkt- und Dienstleistungsentwicklung?
Seit vielen Jahren geben wir Kurse für Requirements Engineering und Management. Vor einigen Jahren kamen dort interessierte Systemingenieure zu uns, die merkten, dass die Spezifikation „ihres“ Systems immer komplexer wird. Sie wollten wissen,
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?
Das Cynefin-Modell von Dave Snowden zeigt sehr schön, dass es nicht ausreicht, als einziges Werkzeug einen Hammer zu haben und damit jedes Problem zu einem Nagel zu machen. Er nennt neben einfachen und komplizierten auch komplexe und chaotische Probleme. Und je nach Kontext brauchen wir unterschiedliche Methoden, Technologien und Praktiken, um ein Problem zu lösen.
Kennen Sie auch folgendes Szenario: Sie sitzen in einem Projektmeeting und der erste Punkt der Agenda steht an: Die aktuellen Metriken. Noch bevor inhaltliche Themen der Entwicklung besprochen werden, wird der aktuelle Status der Metriken als wichtigstes Mittel zur Messung des Projektfortschrittes herangezogen.
Auch dieses Jahr war ich auf dem Tag des Systems Engineering TdSE 2016. Diesmal in Herzogenaurach, 
wo es wieder viele spannende Themen gab [2]. Als Mitglied der Gesellschaft für Systems Engineering (GfSE) und als Experte für Requirements Engineering bei HOOD verfolge ich mit hohem Interesse die Entwicklung des Systems Engineering (SE) im Bezug zum Requirements Engineering (RE). Mich freut es, dass diese „zwei Gebiete“ immer mehr zusammenwachsen und gemeinsam betrachtet werden.
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.