Heute der 4. Teil der Serie “Anforderungen strukturieren” mit der Frage: “Wie gestaltet man eine Struktur mit mehreren Anforderungsdokumenten, Spezifikationen und anderen Anforderungsartefakten?”. Im sogenannten Anforderungs-Informationsmodell wird definiert, welche
Entwicklung muss organisiert und strukturiert werden, das ist klar. Das V kann wohl als das Erfolgsmodell bezeichnet werden, um dieses zu tun. In Deutschland ist es aber nicht nur das standardisierte V Model XT des Bundes, es sind viele Variationen von V-Modellen, die für das Vorgehen in großen und kleinen Produktentwicklungen Pate standen.
Beim RE kommt man nie umhin, auch über Anfragen für weitere Anforderungen zu sprechen. Hierbei geht es jedoch nicht um späte Anfragen für Änderungen nach einem Design-Freeze oder nach Serienreife, welche über ein Change-Control Board laufen, sondern um Anfragen, die bestenfalls bereits in einer frühen Entwicklungsphase berücksichtigt werden sollten. Warum ich heute über Kanban schreibe ist, dass diese Anfragen strukturiert, visualisiert, nachvollziehbar und transparent im Team dargestellt werden müssen. Hierfür eignet sich beispielsweise Kanban. Wie stellt man also sicher, dass Entwicklungsprojekte Anfragen von Kunden umfassend dokumentieren und umsetzen?
Am 27. Juni 2017 haben wir Sie im Blog-Beitrag UX == RE? – mit Gewinnspiel! aufgefordert, an einer Umfrage zum Thema UX (User Experience) teilzunehmen. Nach zahlreichen Rückmeldungen freuen wir uns, Ihnen das Ergebnis dieser Umfrage in Form dieses Blogbeitrages vorstellen zu dürfen.
Beginnen möchte ich mit den Aussagen eins bis drei:
Aussage 1: Der Benutzer steht im Mittelpunkt unserer Entwicklung
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?