Modell einer Anforderung

Erstellt am 24 Juli 2018
von 3 Kommentare

Modell einer Anforderung

Ein Modell ist eine vereinfachte Abbildung der Wirklichkeit mit einem bestimmten Zweck. Das hier vorgestellte Modell hilft mir dabei, herauszufinden, ob eine Anforderung im Kontext einer Produktentwicklung verifizierbar ist. Zudem wird mir dadurch klar, welche der drei Aspekte Stakeholder, Aussage und Adressat einer Anforderung fehlen, unbekannt sind und ggf. ermittelt werden müssen. Die Anwendung dieses Modells hat mir im Übrigen gezeigt, dass auch User Stories und Use Cases Anforderungen sind.

Requirements Engineering für die 3 Amigos

Erstellt am 11 Juli 2018
von Schreibe einen Kommentar

Software beginnt als Idee, als eine Vision. Wenn der Visionär selbst Softwareentwickler ist, reicht das vielleicht schon, um ein großartiges Produkt zu entwickeln. Wenn dieser Visionär aber kein Entwickler ist, muss er das, was in seinem Hirn ist, in die Hirne anderer übertragen, die mit ihm die Software entwickeln. Und das geht nicht ohne Kommunikation.

shutterstock-

Anforderungen mit User Stories und Akzeptanzkriterien agil managen – nur wie?

Erstellt am 25 Januar 2018
von Schreibe einen Kommentar

Haben Sie sich auch schon mal gefragt, wie Sie Anforderungen in Ihrem Produktentwicklungskontext mit User Stories systematisch strukturieren sollten? Unter ständig einprasselnden Kundenäußerungen und neuen Erkenntnissen sollen alle Beteiligten wissen, was gefordert ist. Zudem soll genügend Information vorhanden sein, damit das Geforderte umgesetzt werden kann.
Die Grundlage für diese Fragestellungen bilden Anforderungen. Anforderungen stellen das Bindeglied zwischen Kundenwunsch und dem Produkt(inkrement) dar. In vielen Projekten wird die Frage nach einer Systematik zur Strukturierung von Anforderungen gestellt. An dieser Stelle will ich eine Vorgehensweise vorstellen, um mit Hilfe des sog. generischen Informationsmodells die erforderlichen Verantwortlichkeiten zu klären. Dabei kommen User Stories und Akzeptanzkriterien zum Einsatz.

Abbildung 1: Generisches Informationsmodell für Anforderungen (angelehnt an [2])

Wie der Product Owner die drei Sprachen der User Story lernte

Erstellt am 6 Dezember 2017
von Schreibe einen Kommentar

“Elisabeth Jerichau-Baumann [Public domain], via Wikimedia Commons; (Brothers Grimm)”

Mir wurde einmal folgende Story zugetragen:

Eine junge Frau wurde von einer renommierten Automobilfirma als Entwicklerin eingestellt. Es stellte sich jedoch heraus, dass sie sich schwer tat. Die versierten Kollegen, die das komplexe Software Code System überschauten, sprachen abfällig über sie. Der Chef der Abteilung erkannte, dass doch noch etwas mehr Fortbildung nötig wäre. Sie wurde in ein Kursprogramm eines sehr bekannten Bildungsinstituts geschickt, dort von erfahrenen Meistern des Fachs unterrichtet.

Anforderungen strukturieren – 3. Die Spezifikation

Erstellt am 18 Juli 2017
von Schreibe einen Kommentar
This entry is part 3 of 4 in the series Anforderungen strukturieren

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?

Ziele und Nutzen des systematischen Umgangs mit Anforderungen

Erstellt am 19 Juli 2016
von Schreibe einen Kommentar

Ziele von Anforderungen und Requirements EngineeringKü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.

Eigentlich fast fertig? Die Definition of Done!

Erstellt am 17 Mai 2016
von Schreibe einen Kommentar
Definition of Almost Done

Definition of Almost Done

Es ist Freitag Vormittag, 09:00 Uhr; Zeit für unser Daily. Ein Kollege zeigt auf das Taskboard und sagt “Diese User Story ist eigentlich fertig und kann in unsere Done-Spalte gehängt werden”. Wörter, wie “eigentlich” oder “fast” machen mich stutzig und ich kann nicht anders als nachzufragen, ob die Definition of Done für diese User Story erfüllt ist. Mein Kollege verneint und ergänzt: “Es fehlt noch die Betriebs-Doku”. Ich mache meine Kollegen aufmerksam, dass alle Kriterien der Definition of Done erfüllt sein müssen, damit eine User Story in die Spalte Done geschoben werden kann und somit als abgeschlossen gilt.

Die Anforderung lebt!

Erstellt am 31 Juli 2015
von 1 Komment

Ist das Requirement Engineering tot?

desertDen 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.

Wer bin ich – und wenn ja, wieviele? Requirements Engineers in der Sinnkrise…

Erstellt am 9 September 2014
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Casting für Product Owner

Und es trifft nicht nur die Requirements Engineers (REs), es trifft auch die Business Analysten (BAs), wie ich im Gespräch mit einer Teilnehmerin am Scrum Day erfuhr: „Unsere Entwicklung arbeitet jetzt mit Scrum – und ich weiß gar nicht mehr, was meine Aufgabe ist…“. Dabei ist das Arbeiten als RE/BA in einem Scrum Team herrlich. So vielfältige Aufgaben und Möglichkeiten, sich und sein Wissen einzubringen, habe ich bisher nur beim Arbeiten in einem agilen Team gehabt. Der Transfer der agilen Werte und Prinzipien auf das Requirements Engineering und die Rolle Requirements Engineer in einem agilen Umfeld ist eine Herausforderung für viele Menschen und Organisationen. Die heutigen Zertifizierungen am Markt zu Scrum/Agile und Requirements Engineering haben eines gemeinsam: Sie konzentrieren sich entweder auf das Thema Agilität/Scrum oder auf das Thema Requirements Engineering. Auch “Agile Extensions”, wie sie der BABoK oder das PMI veröffentlicht haben, ergänzen nur die agile Sichtweise, sie bieten keine übergreifende integrierte Sicht. Meine Erfahrung in der Arbeit mit agilen Teams und Organisationen auf dem Weg zu mehr Agilität zeigt jedoch, dass gerade die Verbindung beider Themen in der Praxis Schwierigkeiten macht. Die Transferleistung gelingt nicht oder nur schwer.

Die Qual der Wahl – das Konferenzprogramm der Manage Agile 2014 steht fest

Erstellt am 29 Juli 2014
von Schreibe einen Kommentar

manageagile_2014_quadrat_500pxWir Frauen sind es ja eigentlich gewöhnt aus einem überreichen Angebot auswählen zu müssen. Das geht morgens schon los mit der Frage „Was soll ich anziehen“, setzt sich in der Mittagspause fort mit der Entscheidung ob „Salat, Gemüse, oder doch das Schnitzel“ und (ja, ich bediene jetzt wirklich jedes Klischee) endet mit Verlustgefühlen oder Gewissensbissen nach dem Besuch im Schuhladen (je nach Anzahl der erworbenen Paar Schuhe). Und nein, Sie sind nicht aus Versehen auf dem Blog einer Frauenzeitschrift gelandet – gleich geht’s weiter mit agil.