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!
Anforderungen strukturieren – 2. Techniken
Im letzten Blog „Anforderungen strukturieren – 1. Kriterien“ haben wir vorgestellt, welche Kriterien für die Strukturierung von Anforderungen relevant sind. Heute stellen wir Ihnen im 2. Teil dieser Blog-Serie ein paar Ideen und Konzepte vor, die die Anforderungsstrukturierung ermöglichen. Wir wollen die Frage beantworten: „Welche technischen Möglichkeiten gibt es, um Anforderungen zu strukturieren?“
Anforderungen strukturieren – 1. Kriterien
Die Teilnehmer unseres Trainingsangebotes bringen häufig ein konkretes Problem aus ihrem beruflichen Umfeld mit. Viele wollen wissen, wie man gute Anforderungen schreibt, andere 
wollen einfach die Grundlagen umfassend kennenlernen, die bei dem Umgang mit Anforderungen notwendig sind, sei es im klassischen oder agilen Umfeld.
Eine der häufigsten Fragen lautet: „Ich habe da eine Menge Anforderungen von verschiedenen Seiten in meinem Projekt. Wie strukturiere ich am besten diese heterogenen Anforderungen?“
Wie cool ist Requirements Engineering denn?
…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,
Haben Sie zu viel Geld?
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?
Agil und Traditionell sind keine Gegensätze
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.
Zeig doch mal die Metrik!
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.
Systems Engineering und Requirements Engineering – Gedanken aus dem Tag des Systems Engineering 2016
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.
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.
autoSWIFT: Was können wir zur Beschleunigung von Innovationen aus dem Agilen Manifest lernen?
Komplexe Fahrzeugfunktionen wie das autonome Fahren, Car2Car-Kommunikation und Fahrerassistenzfunktionen stellen die Automobilindustrie vor neue Herausforderungen.