RE CheckUp: Wo stehen Sie im Requirements Engineering?

Erstellt am 22 Dezember 2011
von Schreibe einen Kommentar

Anforderungsmanagement ist inzwischen seit vielen Jahren ein Thema bei Firmen, die komplexe Systeme, Software oder Dienstleistungen entwickeln und anbieten. Oft wurden große Anstrengungen unternommen, Prozesse und Werkzeuge zum Requirements Management zu etablieren. Erfolge sind zweifellos vielerorts zu sehen. Jetzt st es an der Zeit zu erfahren, wie gut etabliert Requirements Engineering in Ihrem Unternehmen inzwischen ist.

HOOD / ReqIF auf dem OMG Meeting in Santa Clara, Kalifornien (Dezember 2011)

Erstellt am 19 Dezember 2011
von Schreibe einen Kommentar

Vom 12. bis zum 16. Dezember 2011 war HOOD auf dem Meeting der
Object Management Group (OMG) in Santa Clara, Kalifornien vertreten.

Thema war unter anderem die Verlängerung der öffentlichen Kommentarperiode für das Requirements Interchange Format (OMG ReqIF) – dies gibt Toolherstellern die Möglichkeit, Probleme bei der Umsetzung besser adressieren zu können. HOOD ist zusammen mit der ProSTEP AG seit Beginn an der Entwicklung des Requirements Interchange Formats beteiligt, für das vor dem OMG Standard das Kürzel “RIF” verwendet wurde. Es ist ein offenenes Austauschformat für Anforderungsspezifikationen zwischen Requirements Management Tools. Bertil Muth (HOOD) ist Vorsitzender der ReqIF Revision Task Force, der Gruppe, die sich bei der OMG um die Weiterentwicklung des Formats kümmert. Die ersten Implementierungen des OMG ReqIF 1.0.1 Standards werden im Rahmen eines Implementor Forums der ProSTEP AG bis Mitte 2012 erwartet. Zudem beteiligt sich HOOD an einem INCOSE Challenge Team, das die Möglichkeiten der Modellierung mit SysML im Rahmen eines großen Teleskopprojekts untersucht. Der Vorschlag des Teams für Variantenmodellierung mit SysML wurde auf dem OMG Meeting diskutiert. Variantenmodellierung ist ein hoch priorisiertes Thema für die zukünftige SysML 1.4 Version.

Formulierungstipps – Teil 2

Erstellt am 13 Dezember 2011
von Schreibe einen Kommentar

Das System muss rot sein.

Ein Leser dieser Anforderung hat eine bestimmte Vorstellung der Farbe Rot. Viele Leser haben viele Vorstellungen – und zwar höchstwahrscheinlich unterschiedliche!

Problematisch ist hier die Verwendung des Eigenschaftsworts „rot“, da es nicht eindeutig definiert ist und daher unweigerlich zu verschiedenen Interpretationen führt.

Wer plant mit welchen Backlogs? – Sichtenwechsel notwendig!

Erstellt am 6 Dezember 2011
von Schreibe einen Kommentar

Kennen Sie auch die Situation, dass Ihre Projekte nicht die optimalen Voraussetzungen für Scrum haben? Sie haben also:

  • Entwickler, die zeitgleich in mehreren Projekten arbeiten.
  • Entwicklungsteam, die auf unterschiedliche Standorte und Zeitzonen verteilt sind.
  • Nur ein auslieferbares Release, wenn die Zulieferung vieler Teams erfolgt ist.

Reif, reifer, aber nicht überreif – Teil 1

Erstellt am 6 Dezember 2011
von 1 Komment

Wenn wir nicht wissen, was wir machen sollen, wie können wir dann jemals erwarten, es richtig zu machen. Wenn wir nicht wissen, warum wir etwas machen sollen, wie können wir erwarten zu wissen, was wir machen sollen.

Akzeptanzkriterien für User Stories definieren – aber nur wie?

Erstellt am 6 Dezember 2011
von 1 Komment

Haben Sie sich auch schon mal gefragt, ob es eine Möglichkeit gibt, Akzeptanzkriterien mit Hilfe eines systematischen Vorgehens zu definieren? Oder wollen Sie eine Basis für Ihre Akzeptanztests schaffen, um festzustellen, ob Ihr System oder Ihre entwickelte Software den Kundenerwartungen entspricht?

Akzeptanzkriterien als  Bindeglied zwischen User Stories und Testfällen 

Die Grundlage für diese Fragestellungen bilden Akzeptanzkriterien, die das Bindeglied zwischen User Stories und den Testfällen darstellen. Da in vielen Projekten die Frage nach einer systematischen Methodik zur Ableitung von Akzeptanzkriterien gestellt wird, soll an dieser Stelle eine Vorgehensweise vorgestellt werden, die auf den sogenannte W-Fragen basiert.

Im Gegensatz zur klassischen Entwicklung ist es im agilen Umfeld ausdrücklich erlaubt, die User Stories erst so spät wie möglich, also kurz vor der Realisierung, zu detaillieren. Eine User Story kann nach dem Muster von M. Cohn erstellt werden.

Die drei “C’s”

Sie sollte aus den sogenannten „3 C’ s“ bestehen. Die ersten beiden “C’s” stehen für “Card” und “Conversation”, das 3. “C” für “Confirmation”. Unter dem Begriff “Confirmation” wird die Definition von Akzeptanzkriterien verstanden, die in der Regel auf der Rückseite einer Karteikarte festgehalten werden. Akzeptanzkriterien leisten gemäß der „Definition of  Done“ einen Beitrag zur Beantwortung der Frage, ob eine User Story fertig ist.

Das Hinterfragen von Schlüsselwörtern

Eine Möglichkeit, Akzeptanzkriterien zu definieren, erfolgt über das Hinterfragen von Schlüsselwörtern. Diese müssen zunächst in der User Story identifiziert werden. Dann können wir nachfolgend prüfen, ob Fragestellungen – basierend auf den sogenannten W-Fragen (wer, wann, wie oft etc.) – mit einer sinnvollen Antwort versehen werden können.

Fragen, die in dem jeweiligen Kontext keine sinnvolle Antwort zulassen, werden ignoriert. Unter Schlüsselwörtern sind Vollverben, Adjektive und Substantive zu verstehen. Das Hinterfragen muss zu einer sinnvollen Antwort führen und eine User Story inhaltlich ergänzen bzw. konkretisieren.
Im Rahmen der Team-Kommunikation kann das Hinterfragen von Schlüsselwörtern dazu beitragen,  zwischen den Stakeholdern ein gemeinsames Verständnis für die anzustrebende Umsetzung zu erlangen. Die Antworten auf die Fragestellungen ermöglichen, konkrete Akzeptanzkriterien zu definieren. Zwischen den Antworten der Stakeholder und den Akzeptanzkriterien muss keine 1:1-Beziehung bestehen, sondern mehrere Antworten können zu einem Akzeptanzkriterium zusammengefasst werden oder eine Antwort zu mehreren Akzeptanzkriterien führen. Die formulierten Akzeptanzkriterien müssen abschließend abgestimmt werden und dienen als Basis für Akzeptanztestfälle.

Anhand der folgenden User Story demonstriere ich die Vorgehensweise:

Zunächst sind Schlüsselwörter zu identifizieren, die im weiteren Vorgehen zu Hinterfragen sind.

Die Schlüsselwörter “speichern” und “Profil” werden in einen vorbereiteten Fragenkatalog eingesetzt.

Die entstandenen Fragen werden im Team diskutiert und sollen die Kommunikation unterstützen und soll mögliche Lücken in der Anzahl der Akzeptanzkriterien schließen.

In nächsten Schritt werden die Antworten auf die Fragen in konkrete Akzeptanzkriterien zusammengefasst.

Die formulierten Akzeptanzkriterien müssen abschließend abgestimmt werden, um im letzten Schritt Testfälle zu erstellen, die dem bewährten Muster

  • Vorbedingung
  • auszuführende Testschritte
  • erwartetes Ergebnis
  • Nachbedingung
  • verwendete Testdaten

entsprechen.

 

Von Akzeptanzkriterien zum erfolgreichen Akzeptanztest

Fazit: Von User Stories abgeleitete Akzeptanzkriterien eignen sich hervorragend, um eine ausreichende Testbasis für den Akzeptanztest sicherzustellen. Bei einer  Vorgehensweise mit Hilfe von fünf Schritten steht die Definition von Akzeptanzkriterien im Mittelpunkt. Ziel soll es dabei sein, die Team-Kommunikation zu unterstützen und konkrete Details zu User Stories zu definieren, um die Basis für einen erfolgreichen Akzeptanztest zu legen. Zudem kann am Beispiel der Definition von Akzeptanzkriterien durch das Hinterfragen von Schlüsselwörtern demonstriert werden, wie eine klassische Methode ins Scrum-Framework eingebettet werden kann.

2

Möchten Sie mehr über Akzeptanzkriterien erfahren? Dann empfehle ich Ihnen, eines unserer beliebten Trainings, wie beispielsweise das zum  Certified Agile Requirements Specialist (CARS) oder zum Scrum Master. 

Einführung von DOORS® Next Generation

Erstellt am 6 Dezember 2011
von Schreibe einen Kommentar

DOORS® von IBM ist der unbestrittene Marktführer unter den Anforderungsmanagement Werkzeugen. Doch die Anforderungen an solche Werkzeuge ändern sich mit der Zeit. Während in den letzten Dekaden das Thema Traceability den größten Raum eingenommen hat, kommen heute verstärkt Themen wie Wiederverwertbarkeit von Anforderungen und Zusammenwirken in internationalen Teams in den Focus. Der Trend geht hin zu einer gesamtheitlichen Betrachtung über den gesamten Lebenslauf einer Produktlinie.

Formulierungstipps – Teil 1

Erstellt am 6 Dezember 2011
von Schreibe einen Kommentar

Nach Drücken der Taste müssen die Daten übertragen werden.

In der nun folgenden Blogserie werden wir Ihnen zahlreiche Tipps geben, wie Sie die oben genannte und weitere schwach formulierte Anforderungen verbessern können.

Durch die Tatsache, dass die Anforderung im Passiv formuliert ist, wird keine Aussage darüber gemacht, wer oder was die Daten übertragen muss. Es fehlt also der Akteur, der den zu entwickelnden Gegenstand darstellt.

Teure Anforderungen

Erstellt am 6 Dezember 2011
von Schreibe einen Kommentar

Schwach formulierte Anforderungen können sich zu teuren Anforderungen entwickeln. Dies lässt sich durch einfache Maßnahmen vermeiden.

Vielen laufen sie tagtäglich über den Weg – „Anforderungen mit Verbesserungspotential“. Zur Verdeutlichung sollen hier zwei eindrückliche Beispiele genannt sein: „Nach Drücken der Taste müssen die Daten übertragen werden.“ oder „Das System muss leicht bedienbar sein.“.