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?
UX == RE? – mit Gewinnspiel!
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 langfristig dokumentieren, im agilen Umfeld
In unserem CARS-Training diskutieren wir viele Themen, unter anderem: wie dokumentiert man Anforderungen langfristig, im agilen Umfeld?
Diese Frage ist für uns deshalb so wichtig, weil der Wert der Dokumentation mit der Zeit zunimmt.
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?“
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,
Wenn der Termin drückt, werden Strukturen aufgebrochen
Kennen Sie das auch?: Der Endtermin für ein Projekt rückt immer näher, aber die Arbeit ist noch nicht erledigt. Das Projektziel ist nicht klar, oder wird immer wieder angepasst. Es gibt ständig neue Änderungen an den Anforderungen. Der ursprüngliche Zeitplan passt vorne und hinten nicht mehr. Einzig der Termin für die Markteinführung des Produkts steht fest und muss erfüllt werden!
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?
Projekterfolg erleben
Es gibt nichts motivierenderes als den Erfolg eines Projektes selbst zu erleben. „Die Lorbeeren gemeinsam mit Kollegen zu ernten!“ Mein Kollege Marco Prillwitz und ich konnten dies in einem Kundenprojekt nun miterleben. Hier die Geschichte:
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.
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.