SOPHIST News

Bloggen - Zeit für was Neues

tim.schwitalski — Fri, 08 Mar 2013 17:00:00 +0100

Wir könnten Ihnen jetzt beschreiben, wie unsere Welt (und auch Ihre;) ) dauerhaft Veränderungen unterworfen ist.

Wir könnten Ihnen beschreiben, wie jede Sekunde, jede Minute, jeder Tag von Änderungen erfüllt ist. Wir könnten darüber sinnieren, dass diese Änderungen sowohl negativer, als auch positiver Natur sein können. Wir könnten Ihnen erläutern, wie wichtig Änderungen sind, das Änderungen auch als Motor fungieren können, also als etwas, das uns antreibt. Wir könnten Ihnen Beispiele zeigen, wie das Denken und Handeln von Veränderungen beeinflusst wird.

Wir könnten Ihnen aber auch einfach nur sagen:
Unser Blog ist neu!

Und um Sie schnell ins Wochenende zu entlassen, hier die Fakten, die Ihnen diese Veränderung schmackhaft machen werden:

Bessere Durchsuchbarkeit: profitieren Sie von unserer neuen Suchfunktion und finden Sie die Artikel, die sie benötigen.
Bessere Lesbarkeit: ein angenehmerer Bildaufbau ermöglicht das ermüdungsfreie Lesen.
Bessere Sortierbarkeit: picken Sie Ihren Lieblingsautor heraus, schauen Sie was die SOPHISTen im Dezember 2009 gemacht haben oder lassen Sie sich anzeigen, welche Konferenzen die SOPHISTen besucht haben.
eine ausgereifte Kommentarfunktion: treten Sie in den Dialog mit uns und sagen Sie uns Ihre Meinung.
feste Blogzeiten: stellen Sie sich auf unsere Blogartikel ein und die neusten Berichte aus der Welt des Requirements Engineering.

Unseren neuen Blog finden Sie unser blog.sophist.de. Wir wünschen viel Spaß bei der neuen Leseerfahrung! Mit besten Grüßen, Ihre SOPHISTen

Durchblick im Schablonendschungel – Teil 2

Wed, 06 Mar 2013 16:00:00 +0100

Im letzten Teil dieser Blogserie haben wir Ihnen die SOPHIST-Schablone und ein Template von Esser und Struss als erste Möglichkeiten vorgestellt, die Ihnen bei der Formulierung von Anforderungen helfen sollen. Als durchgängiges Beispiel hatten wir Ihnen den Satz: „Wenn sich der Inhalt einer Datei ändert, geht der Zustand der Datei nach „geändert“ über.“ vorgegeben. Heute präsentieren wir Ihnen weitere Vorlagen zum Schreiben von Anforderungen.

Von Alistair Mavin stammt EARS+, die nächste Schablone, die wir Ihnen hier darstellen. Er entwickelte sie bei Rolls Royce plc., um Anforderungen an Flugzeugturbinen korrekt zu spezifizieren. Daneben hat aber auch bspw. Intel EARS+ im Einsatz. Ausgesprochen bedeutet die Abkürzung „Easy Approach to Requirements Syntax Plus“.

Im Folgenden sehen Sie die Schablone. Obligatorische Bestandteile sind fett dargestellt, optionale Bestandteile nicht fett. Die Zahlen dienen der Zuordnung der einzelnen Elemente im Beispiel zu den Bestandteilen der Schablone.


While ¹ ², when ³ ⁴ ⁵⁶ ⁷, the ⁸ shall ⁹ ¹⁰ ¹¹ ¹² ¹³¹⁴ ¹⁵.

Diese Schablone ist schon viel detaillierter und damit leider auch etwas unübersichtlicher, als die beiden das letzte Mal vorgestellten. Doch keine Angst, A. Mavin liefert auch gleich ein Beispiel mit: While ², when ³ ⁴ ⁵ ⁶ ⁷, the ⁸ shall ⁹ ¹⁰ ¹³ ¹⁴ and ⁹ ¹⁰ ¹¹ <“please take your card”>¹² ¹³ Customer>¹⁴. Unser Beispiel, geschrieben nach EARS+ würde wie folgt lauten: While ¹ ², when ⁵ ⁷, the ⁸ shall ⁹ ¹⁰ ¹² ¹⁵. Da viele Dinge nur optional sind, lässt sich das Detaillierungsniveau der Anforderungen sehr variabel gestalten. Sie können selbst entscheiden, auf welchem Spezifikationslevel Sie Ihre Anforderungen schreiben – eher abstrakt oder eher detailliert. EARS+ bietet beides und hilft Ihnen extra noch, keine Informationen im Anforderungssatz zu vergessen. Wir SOPHISTen sehen neben der Komplexität der Schablone vor allem einen Nachteil darin, dass durch den -Anteil nichtfunktionale Aspekte mit der funktionalen Anforderung vermischt werden. Nach Regel 9 unseres REgelwerks sollten Sie eigene Anforderungen für nichtfunktionale Aspekte formulieren, wenn:

der nichtfunktionale Anteil eigenständig testbar ist, oder

der nichtfunktionale Aspekt übergreifend als ein nichtfunktionales Constraint für mehrere Funktionalitäten gefordert wird.

Die nächste vorzustellende Schablone wurde von der Information Architecture Group (IAG) für Anforderungen entwickelt, die bei der Automatisierung von Geschäftsabläufen erhoben werden. Damit sollen Business Use Cases in eine einheitliche Form gebracht werden¹. Die Schablone lautet:


The system must ... [..do something..] action verb [..with some information..] business entity/attribute [..under certain circumstances..] when/if [..according to certain rules..] business rules

Auch zu dieser Schablone liefern die Entwickler ein Beispiel, in welchem aber leider die Geschäftsregeln außen vor gelassen werden: „The system must
   allow the Reservation Clerk
       to select one instance from a list of potential Guests
           when the Reservation Clerk has determined the appropriate occurance.”
Unser Beispiel, formuliert nach dieser Schablone, wäre wie folgt:
“The file system must
    set
        the state of a file to “changed”
            when the content of the file is changed
                if the file was in state “backed up”.” Eine Besonderheit dieser Schablone ist, dass sie mehr den allgemeinen Inhalt vorgibt. Damit ist sie mehr eine Semantik- und weniger eine Syntax-Schablone als die anderen hier vorgestellten.
Ansonsten würden wir die Schablone als nicht zu ungenau, nicht zu detailliert, nicht zu komplex, nicht allzu formal einordnen. Das letzte in diesem Teil vorgestellte Template wurde von Jörg Holtmann im Rahmen des Projekts „Software Platform Embedded System 2020 (SPES 2020)“ zur modellbasierten Entwicklung von eingebetteten Systemen im Automotive-Bereich, entwickelt. Er erarbeitete mehrere Templates, um automatisiert Modelle aus textuellen Anforderungen abzuleiten. Dazu implementierte er auch einen auf Eclipse basierenden Editor, der beim Dokumentieren von Anforderungen und Umwandeln in Diagramme hilft. Seine Schablone lautet:


{Wenn \| Sobald} im [Zustand] "" des Systems " das Ereignis "" eintritt [und die Bedingung '' erfüllt ist], geht es in den [Zustand] "" über [; parallel dazu wird die Funktion "" aktiviert].

Sein Beispiel dazu lautet: „Sobald im Zustand Startup des Systems „Innenlichtsteuerung“ die Zeit abgelaufen ist, geht es in den Zustand „Ready“ über.“ Daneben auch unser Beispiel: Sobald im „backed up“ des Systems „Datei“ das Ereignis „Inhalt der Datei geändert“ eintritt, geht es in den Zustand „geändert“ über. Diese Schablone gibt einen sehr formalen Rahmen vor. Sie eignet sich damit perfekt, falls neben der natürlich-sprachlichen Anforderungsermittlung auch gleichzeitig ein Zustandsautomat modelliert wird. Dieser hohe Grad an Formalität wirkt sich positiv auf die Vollständigkeit der Anforderungen aus, so wird beispielsweise beachtet, ob alle Zustände und deren Übergänge spezifiziert sind. Weiterhin verhindert dies einige Ungenauigkeiten, so sind z.B. die nach Holtmann formulierten Anforderungen testbar, eine wichtige Eigenschaft von Anforderungen. Jörg Holtmann geht davon aus, dass neben der natürlich-sprachlichen Dokumentation auch eine modellbasierte verwendet wird. Ist das bei Ihnen nicht der Fall, ist fraglich, ob dieser hohe Grad an Formalität unbedingt notwendig ist. So lassen sich mit der SOPHIST-Schablone Anforderungen viel freier und einfacher dokumentieren, die aber deswegen nicht zwangsweise von minderer Qualität sind. Nachdem die Schablonen für funktionale Anforderungen abgeschlossen sind, kommen wir nun zu den Schablonen für nichtfunktionale Anforderungen – aber leider erst im dritten Teil unserer Blogserie. Da stellen wir Ihnen NoFun vor. Seien Sie gespannt – der Name ist Programm! :-)
¹IAG Consulting – 7 Secrets to Defining Requirements for Package Software Selection

Wissen richtig vermitteln – Chris Rupp und Carsten Pflug zeigen Ihnen auf der REConf 2013 wie

Fri, 01 Mar 2013 09:57:00 +0100

Auch dieses Jahr sind wir auf der REConf 2013 in München mit einem Vortrag und Messestand dabei. Chris Rupp und Carsten Pflug halten am Dienstag, 12.03.2013 von 16:40 Uhr bis 17:25 Uhr im Raum Rom den Vortrag „Wissensvermittlung bei der Einführung von Requirements Engineering Methoden“. In dem Vortrag geht es darum, wie Wissen bei der Einführung einer neuen RE-Methode an Projektbeteiligte vermittelt werden kann. Denn eine neue RE-Methoden einführen kann nur funktionieren, wenn alle Betroffenen die Methode verstehen und umsetzen können. Daher muss das Wissen über die neuen Methoden effektiv vermittelt werden. Allerdings bringt nicht jede Vermittlungsmethode auch den gleichen Erfolg.
Chris Rupp und Carsten Pflug zeigen, wie Sie die Einflussfaktoren und die daraus resultierende geeignete Vermittlungsmethode herausfinden und somit alle Projektbeteiligte genau das Wissen erlangen können, welches sie benötigen. Möchten Sie uns (mal wieder) sehen, mit uns sprechen, kennenlernen, diskutieren, Wissen austauschen, lachen und vieles mehr? Dann besuchen Sie uns doch einfach an unserem Messestand Nr. 24. Wir freuen uns auf Sie und haben auch ein paar nette Sachen im Gepäck :-) Weitere Informationen finden Sie hier. Viele Grüße
Ihre SOPHISTen

CPRE AL - Requirements Modeling: Datenflussmodellierung (Teil I)

Wed, 27 Feb 2013 17:06:00 +0100

Im Lehrplan des Certified Professional for Requirements Engineering Advanced Level – Requirements Modeling des IREB e.V. (Lehrplan) ist in Lehreinheit 3.3 Funktionsmodellierung die Datenflussmodellierung beinhaltet. Da die Literatur zu diesem Thema evtl. nicht bei jedermann vorhanden ist und falls doch sehr viel ausführlicher sein dürfte als dies der Lehrplan fordert, möchte ich die wichtigsten Aspekte der Datenflussmodellierung im Rahmen dieser kleinen Blogserie – bestehend aus drei Teilen – erklären. Im Teilmodell Funktionsmodell des gesamten Anforderungsmodells werden einerseits Aktivitätsdiagramme der UML eingesetzt, um ablauforientierte Funktionen zu dokumentieren. Andererseits können jedoch auch Datenflussdiagramme verwendet werden, um Funktionen wie z.B. Use-Cases datenflussorientiert zu beschreiben und zu zerlegen. Wir bewegen uns mit der Datenflussmodellierung also in der Funktionsperspektive zur Beschreibung eines Systems. Historie: Die Datenflussmodellierung lässt sich zurückführen auf Tom DeMarco. In seinem Werk Structured Analysis and System Specification [DeMarco] aus dem Jahr 1979 stellt er die Datenflussdiagramme als wichtigen Bestandteil der Strukturierten Analyse vor. Seitdem wurden die Strukturierte Analyse und damit auch die Datenflussmodellierung zwar weiterentwickelt, die Grundprinzipien und wichtigsten Aspekte derer gelten jedoch noch heute. So auch eine grundlegende Definition der Datenflussmodellierung: „Bei der Datenflussmodellierung geht es um die Modellierung des Datenaustausches zwischen den Funktionen eines Systems und der Umwelt.“ [EDW] Bereits im CPRE Foundation Level werden die Datenflussdiagramme eingeführt. Dazu müssen zunächst die vier Notationselemente der Datenflussdiagramme behandelt werden. Sie werden im Rahmen des CPRE Advanced Level – Requirements Modeling wiederholt. Es handelt sich dabei um die Notationselemente:

Prozess: Ein Prozess stellt eine Funktion des betrachteten Systems dar. Er erhält Eingangsdaten durch eingehende Datenflüsse, verändert diese Daten (die eigentliche Funktion, die der Prozess darstellt) und gibt die veränderten Daten auf ausgehenden Datenflüssen wieder aus.
Datenfluss: Datenflüsse verbinden Prozesse, Terminatoren und Datenspeicher miteinander und geben an in welche Richtung welche Daten zwischen den anderen Notationselementen laufen.
Terminator: Terminatoren sind externe Partner des betrachteten Systems, wie Menschen, die das System bedienen (z.B. Daten eingeben, die in einem Prozess benötigt werden) oder andere technische Bestandteile, Komponenten, Geräte, etc..
Datenspeicher: In Datenspeichern werden Daten abgelegt. Dies geschieht durch eingehende Datenflüsse. Ebenso können Daten auch aus einem Datenspeicher gelesen werden, z.B. wenn Sie zur Ausführung eines Prozesses benötigt werden. Dies geschieht mit ausgehenden Datenflüssen.

Mit Hilfe dieser vier Notationselemente, die die Datenflussmodellierung ausmachen, können Datenflussdiagramme modelliert werden, wie folgende Abbildung mit einem Beispiel zu einer Temperatursteuerung eines Computers zeigt: Datenflussdiagramm Temperatursteuerung Dieses Datenflussdiagramm stellt die Gesamtsicht auf das System mit seiner Umwelt dar. Die Prozesse sind benannt und mit eingehenden und ausgehenden Datenflüssen versehen. Ebenso ist sichergestellt, dass Prozesse Daten nicht nur „durchreichen“, sondern diese tatsächlich verändern. Doch als vollständige Beschreibung der Funktionssicht eines Systems reicht diese Ebene der Modellierung nicht aus. Die Funktionen des Systems – hier die Prozesse – müssen näher untersucht und verfeinert werden. Die Datenflussmodellierung lässt genau diese Zerlegung zu, indem Prozesse verfeinert werden können und auf einer detaillierteren Ebene genauer beschrieben werden, wie die Abbildung „Hierarchische Zerlegung von Prozessen“ schematisch zeigt.
Hierarchische Zerlegung von Prozessen Zur Hierarchischen Zerlegung in der Datenflussmodellierung sollte man sich drei Aspekte merken bzw. beachten:

Ein Prozess kann durch ein verfeinerndes Datenflussdiagramm beschrieben werden.
Bei geeigneter Wahl der Zerlegung kann ein komplexes Modell schrittweise in einfachere Teilmodelle zerlegt werden.
Die Datenflussdiagramme eines Systems können hierarchisch in Schichten angeordnet werden.

So baut sich durch die Verfeinerung von Prozessen durch weitere Datenflussdiagramme auf der jeweils nächsten Detaillierungsebene eine Baumstruktur von Datenflussidagrammen auf. Das Diagramm, das den Wurzelknoten dieser Baumstruktur darstellt – also unser oben gezeigtes Beispiel Temperatursteuerung – wird in der Strukturierten Analyse übrigens auch als Kontextdiagramm bezeichnet. Nun möchte ich aber am Ende dieses ersten Teils zum Themengebiet Datenflussmodellierung noch einen Vorschlag für ein Datenflussdiagramm, welches den Prozess 3. Temperatur überwachen aus unserem Beispiel Temperatursteuerung verfeinert, machen: Verfeinerung des Prozesses 3. Temperatur überwachen Gehört der Benutzer mit in dieses Diagramm? Warum laufen Datenflüsse ins Nichts? Warum kommen Datenflüsse aus dem Nichts? Diese und weitere Fragen werde ich im zweiten Teil dieser Blogserie beantworten, in dem es u. a. um die sogenannten Balancing Regeln gehen wird.
Quellen & Literatur
[DeMarco] DeMarco, Tom: Structured Analysis and System Specification. Prentice Hall, New Jersey, 1979. [EDW] Enzyklopädie der Wirtschaftsinformatik; Myrach, Thomas, Prof. Dr.

CPRE in Zahlen

Wed, 20 Feb 2013 17:20:00 +0100

Vor kurzem überschritt die Anzahl der CPRE-Zertifizierten weltweit die stolze 10.000. Auch wenn Zahlen oft mit dem negativ behafteten Wort Salat in Verbindung gebracht werden, lohnt sich an dieser Stelle ein Blick auf eben diesen Zahlensalat. 2012 haben die Trainingsprovider des IREB weltweit insgesamt 355 CPRE-Trainings gehalten. Schmackhaft geht es weiter: Insgesamt 90% von diesen Trainings bestanden aus dem CPRE Foundation Level.
Mit 8% und 2% runden Trainings bei den Advanced Leveln Requirements Modeling und Elicitation & Consolidation den Geschmack ab. Ein Augenschmaus ist auch die folgende Zahl: Mit stolzen 23% hat SOPHIST einen Großteil aller Trainings durchgeführt (81 der 355 Trainings). Schauen wir uns die einzelnen Zutaten genauer an: Mit gut einem Fünftel ist SOPHIST einer der führenden Trainingsprovider beim Foundation Level (weltweit gibt es bereits über 70 Trainingsprovider für den Foundation Level). 62 der 319 stattgefundenen Trainings aus diesem Level wurden von uns gehalten. Bei den Trainings CPRE Advanced Level Requirements Modeling und CPRE Advanced Level Elicitation & Consolidation haben wir sogar 52% der vom IREB anerkannten Trainings gehalten (19 von 36 Trainings). Die professionelle CPRE-Ausbildung unserer Kunden bei den verschiedenen Leveln ist für uns mit Abstand die wichtigste Zutat. So kommt es auch nicht von ungefähr, dass viele Teilnehmer auf den Geschmack gekommen sind, gerade bei SOPHIST ein Training zu besuchen: 2012 wurden 48% der Teilnehmer von ihren Kollegen auf unser Trainingsangebot aufmerksam gemacht. Diese Mund-zu-Mund-Propaganda ehemaliger Teilnehmer freut uns natürlich, zeigt sie doch, dass unsere Trainings als überaus gewinnbringend in Erinnerung bleiben und auch den Kollegen zu dieser positiven Trainingserfahrung bei SOPHIST geraten wird. Das ist für die SOPHISTen Motivation genug, auch weiterhin professionelle und qualitativ hochwertige Trainings anzubieten. Sie wollen sich auch professionell ausbilden lassen? Hier finden Sie unser Angebot.

Durchblick im Schablonendschungel - Teil 1

Tue, 12 Feb 2013 15:54:00 +0100

Ging es Ihnen auch schon einmal so, dass Sie eine Anforderung aufschreiben wollten, und einfach nicht wussten, wie Sie sie am besten formulieren? Damit Ihnen das in Zukunft nicht noch einmal passiert, möchten wir Ihnen hier verschiedene Werkzeuge vorstellen, die Sie beim Schreiben von Anforderungen verwenden können.

Es existieren verschiedene Ansätze, das Schreiben von Anforderungen durch Schablonen zu vereinheitlichen und zu vereinfachen. Wir haben den Markt durchsucht und dabei über 30 Vorlagen gefunden. Das Spektrum reichte von Modellen über das Vorgehen, bspw. der NFR-Methode (Non Functional Requirements) von Jörg Dörr (1) bis hin zu simplen Sammlungen von Anforderungen wie der Referenz-Beispiel-Datenbank aus IVENA, die einen Katalog von Anforderungen enthalten, aus denen Sie sich Ihre zusammensuchen können. Aus diesen 30 Templates haben wir die 5 ausgewählt, die als echte Satzschablonen die Struktur eines Anforderungssatzes vorgeben, und diese miteinander verglichen.

Nachfolgend stellen wir Ihnen diese 5 Schablonen vor: EARS+, NoFun, eine von M. W. Esser und P. Struss, eine der IAG Consulting sowie eine von Jörg Holtmann. Wir erläutern, in welchem Kontext sie am besten geeignet sind, und zeigen Vorteile und Nachteile der einzelnen Schablonen auf. Ausgangspunkt dieses Vergleichs war die Satzschablone der SOPHISTen, die wir als 6. Schablone hier präsentieren.

Zum Schreiben von funktionalen Anforderungen entwickelten auch die SOPHISTen vor über einem Jahrzehnt eine Satzschablone. Funktionale Anforderungen sind nach der Definition des IREB (International Requirements Engineering Board) Anforderungen bezüglich eines Ergebnisses oder eines Verhaltens, das von einer Funktion eines Systems bereitgestellt werden soll.
Diese Schablone sieht wie folgt aus:

Klicken Sie hier um das Bild zu vergrößern

Mit der SOPHIST-Schablone lassen sich die meisten funktionalen Anforderungen formulieren. Gleichzeitig werden sprachliche Mängel wie Tilgung oder Generalisierung vermieden. So wird zum Beispiel durch die Vorgabe des Aktivs der Anwender gezwungen, denjenigen zu beschreiben, der die Funktion ausführen soll.

Um Ihnen die Anwendung der Schablonen nahe zu bringen, gießen wir bei jeder Schablone den frei formulierten Satz „Wenn sich der Inhalt einer Datei ändert, geht der Zustand der Datei nach „geändert“ über.“ in die durch die Schablone vorgegebene Form.

Nach SOPHIST-Schablone geschrieben lautet diese Anforderung: „Falls sich eine Datei im Zustand „gesichert“ befindet und sobald sich der Inhalt der Datei ändert, muss das Dateisystem den Zustand der Datei in den Zustand „geändert“ ändern.“

Neben einer Schablone für das Schreiben von deutschen Anforderungen gibt es auch noch eine Schablone für englische Anforderungen. Da einige Schablonen, die wir Ihnen im Rahmen dieser Blogserie vorstellen möchten, für die englische Sprache erstellt wurden, formulieren wir unsere Beispielanforderung auch in Englisch. Dies soll Ihnen den Vergleich erleichtern:

Bitte klicken Sie hier um das Bild zu vergrößern If a file is in state „backed up” and as soon as the content of the file changes, the file system shall change the state of the file to “changed”.

Die erste Schablone, die wir Ihnen vorstellen möchten, wurde von M. W. Esser und P. Struss entworfen, um automatisch Testfälle aus natürlich-sprachlichen Dokumentationen der Steuerungssoftware von Fahrzeugen abzuleiten.

Esser und Struss präsentieren dafür folgende einfache Schablone (2):

In ihrem Essay präsentieren sie die Schablone mit dem Beispiel: “If button B4 has not been down during the last 5 seconds, then lamp L3 must be lit immediately.”

Für unsere Beispielanforderung geschrieben nach dieser Schablone ergibt sich: “If the content of a file has been changed, then the state of the file must be set to „changed“.

Eine ganz große Stärke dieser Schablone ist ihre Simplizität. Sie lässt sich ganz einfach auswendig lernen und anwenden. Wir wetten, Sie schaffen es, diese Schablone anzusagen, ohne nach oben zu schauen.

Eine weitere Stärke ist, dass sich aus den Anforderungen ziemlich leicht Testfälle ableiten lassen, was ja das Ziel der Entwicklung dieser Schablone war. So müsste in unserem Beispiel der Tester den Inhalt der Datei ändern und anschließend den Zustand der Datei überprüfen. Ist der Zustand gleich „geändert“, ist der Test bestanden, ist der Zustand nicht „geändert“, ist der Test nicht bestanden.

Ein Nachteil dieser Schablone ist ihre Ungenauigkeit. So bleibt bspw. ungeklärt, wer die Aktion, die Änderung des Zustands, ausführt. Gerade bei der Formulierung von Anforderungen ist die Angabe des Akteurs aber entscheidend, da für den Entwickler wichtig ist, ob die Aktivität vom System, vom Nachbarsystem oder vom Benutzer durchgeführt wird. Für den Test auf Funktionalität ist diese Information insofern nebensächlich, dass der Tester überprüft, ob die Funktion korrekt ausgeführt wird. Die Implementierung interessiert ihn nur sekundär.

Das soll es fürs Erste gewesen sein. In den nächsten Teilen der Blogserie werden wir weitere Templates für funktionale Anforderungen vorstellen, bspw. EARS+ oder ein Ansatz von Jörg Holtmann, sowie ein Template für nichtfunktionale Anforderungen mit dem Namen NoFun. Seien Sie gespannt, der Name ist Programm.

Bis bald.

Ihre SOPHISTen Hier finden Sie den 2. Teil der Blogserie.
---------------------------------------------------------------------
(1) Jörg Dörr. Elicitation of a Complete Set of Non-Functional Requirements. PhD Thesis, Technische Universität Kaiserslautern, Kaiserslautern, 2010.
(2) http://mqm.in.tum.de/publications/2007/Esser%20Struss%20Models%20for%20TG%20from%20Natural-language-like%20Specifications%20DX07.pdf

User Stories – Ermittlungs- oder Dokumentationstechnik? TEIL III: Abnahmekriterien und das Hinterfragen von User Stories

Wed, 30 Jan 2013 14:45:00 +0100

Nach den Grundlagen in Teil I und den gängigen Qualitätsmaßstäben für User Stories in Teil II beschäftigen wir uns in diesem Teil der Blogserie zur unterstützenden Technik „User Stories“ mit Abnahmekriterien und einer Fragetechnik, die es erlaubt, die Hintergrundinformationen zu ermitteln, die zum Verständnis (und damit für die erfolgreiche Umsetzung!) einer User Story notwendig sind.

Abnahmekriterien, auch manchmal als „Akzeptanzkriterien“ (vom englischen acceptance criteria) bezeichnet, dienen zur Dokumentation der Aspekte, die der jeweilige User Story-Verantwortliche für wichtig erachtet, damit er mit der Umsetzung seiner User Story zufrieden ist. Ein festes Format gibt es für Abnahmekriterien nicht, allerdings wird oft ein Aufbau verwendet, der einem Testfall oder Szenario ähnelt, das Given-When-Then-Schema, hier in übersetzter Form:

Angenommen ,
Wenn ,
dann .

Die geltenden Voraussetzungen, Benutzeraktionen und Reaktionen des Systems können von einigen Parametern bis hin zu komplexen Szenarien reichen, und eine User Story kann (und wird in den meisten Fällen) mehrere Sets dieser Abnahmekriterien besitzen.

Abnahmekriterien nach dem Given-When-Then-Schema unterstützen die testgetriebene Entwicklung (TDD) und stellen sicher, dass der Kunde ein klares Bild davon hat, was er genau möchte. Das Given-When-Then-Schema ist allerdings nicht zwingend erforderlich. Solange allen Beteiligten klar ist, worum es geht, und was getan werden muss, um die User Story zu implementieren, ist die Dokumentationsform irrelevant.

Als weitere Methode, um zu guten User Stories zu kommen, wird auch die Ursprungsursachenanalyse (root cause analysis), bzw. “5 Warums“ (5 Whys) genannt – das bis zu fünfmalige Hinterfragen der gewünschten Funktionalität oder Eigenschaft mit der Frage „Warum?“. Die Anwendung dieser Methode beherrscht schon jedes Kind nahezu perfekt… nur dass Kinder sich selten auf fünfmal Fragen beschränken.

Ein Beispiel zur Anwendung der Ursprungsursachenanalyse für User Stories findet sich in Cory Foys Blog [1]


Entwickler:	Warum muss das System mit mehrfachen Zuordnungsanfragen umgehen können?
Kunde:	Weil einige Bestellungen aufgeteilt werden müssen.
Entwickler:	Und warum müssen sie aufgeteilt werden?
Kunde:	Weil nicht alles auf eine Palette passen wird.
Entwickler:	Warum wird nicht alles drauf passen?
Kunde:	Weil wir nur eine bestimmte Anzahl von einem Gegenstand auf eine einzelne Palette packen können. Es gibt nur begrenzt Platz um das Zeug sicher zu stapeln.
Entwickler:	Und warum beeinflusst das das System?
Kunde:	Weil wir nicht wollen, dass Kunden über die Palettenaufteilung nachdenken müssen. Wir wollen, dass sie einfach ihre Bestellung aufgeben können und das System errechnet, wie viele Paletten dafür benötigt werden.

Sind User Stories nun eher eine Ermittlungstechnik oder eine Dokumentationsform? Eine Antwort könnte lauten: Ein bisschen von beidem. Was denken Sie dazu? Wir freuen uns über Mail zu Ihren persönlichen Erfahrungen mit User Stories an heureka@sophist.de. Quellen:
[1] http://blog.coryfoy.com/2011/03/breaking-down-features-to-user-stories/

Chris Rupp auch weiterhin im Vorstand des IREB e.V.

Mon, 28 Jan 2013 15:51:00 +0100

Ende des vergangenen Jahres fanden auf der Mitgliederversammlung die ordentlichen Wahlen zu den Vorstandsvorsitzenden des IREB e.V. statt. Unsere Chris Rupp bleibt auch weiterhin 1. Vorsitzende! Für eine weitere Amtsperiode von 2 Jahren wird sie nun versuchen, den Planeten zu gutem Requirements Engineering zu konvertieren. Hierfür liegen ihre Ziele ganz klar auf der Internationalisierung des IREB und der Etablierung des CPRE als einheitlichem Standard. Der Ausbau der Advanced Levels und eine weitere Steigerung der bekanntermaßen hohen Qualität gehen damit einher. Rainer Grau (Zühlke Engineering AG) und Karol Frühauf (Infogem AG) wurden ebenfalls in ihren Ämtern als 2. Vorsitzender und Schatzmeister bestätigt. Chris Rupp bedankt sich für das in sie gesetzte Vertrauen und freut sich auf die zukünftige Zusammenarbeit mit den Vorstandskollegen und dem Board. Wir wünschen dem IREB e.V. viel Erfolg bei der Verwirklichung seiner Ziele!

Chris Rupp remains First Chairperson of the IREB e.V. Board

Mon, 28 Jan 2013 15:47:00 +0100

At the end of last year, the regular elections for the board members of the IREB e.V. were held at the general meeting.
Our Chris Rupp was reelected as first chairperson! For an additional tenure of two years, she will now try to convert the planet to good requirements engineering. In this regard, her goals lie firmly in the internationalization of the IREB and in establishing the CPRE as a uniform standard. Extending the advanced levels and increasing the well-known high quality are part of achieving these goals.
Rainer Grau (Zühlke Engineering AG) and Karol Frühauf (Infogem AG) have also been confirmed in their offices as second chairperson and treasurer.
Chris Rupp would like to thank you for the trust placed in her and is looking forward to the future cooperation with her fellow board members.
We wish the IREB e.V. every success in realizing its goals!

User Stories – Ermittlungs- oder Dokumentationstechnik? TEIL II: Maßstab für Qualität – die INVEST- und die SMART-Formel

Thu, 24 Jan 2013 14:30:00 +0100

In Teil I unserer Blogserie zur unterstützenden Technik „User Stories“ haben wir uns mit dem Hintergrund und dem Aufbau von User Stories beschäftigt. In diesem Teil erfahren Sie, woran die Qualität von User Stories erzeugt, bzw. gemessen werden kann.

User Story-Standardform hin oder her, man kann in User Stories immer noch viel hineinschreiben, denn (virtuelles) Papier ist bekanntlich geduldig. Es gibt allerdings zwei Formeln, mit deren Hilfe eine gewisse Grundqualität erreicht werden soll: die INVEST-Formel und die SMART-Formel (siehe auch [1]). Eine „gute“ User Story nach der INVEST-Formel sollte folgende Eigenschaften besitzen:


Independent–	unabhängig von anderen User Stories und daher auch einzeln umsetzbar.
Negotiable –	verhandelbar; Diese Eigenschaft betont, dass eine User Story nur die Essenz der Anforderung enthält und die Details in der Diskussion festgelegt werden.
Valuable –	wertvoll, also von echtem Nutzen für einen Kunden, so dass er für die Umsetzung etwas bezahlen würde.
Estimable –	abschätzbar im Aufwand für die Umsetzung. Das schließt mit ein, dass klar werden muss, worum es in der User Story geht. Nicht verstandene User Stories können nicht oder nur schwer geschätzt werden.
Small –	klein genug, dass sie nicht mehr als eine Personen-Woche oder ein paar Personen-Tage an Arbeit umfasst. Diese Vorgabe soll auch Schwierigkeiten mit zu vagen oder umfassenden User Stories verhindern.
Testable –	überprüfbar; Der Kunde muss in der Lage sein, klare Angaben dazu zu machen, unter welchen Bedingungen die User Story als umgesetzt bzw. erfüllt gilt.

Die SMART-Formel wird gerne als Kriterium für die Aufgabenplanung im Zeitmanagement genutzt. Im Zusammenhang mit User Stories bezieht sie sich vor allem auf die Zerlegung einer User Story in einzelne Aufgaben während der Implementierung, oder auf Abnahmekriterien. SMART steht für:


Specific –	konkret; Aufgaben müssen konkret genug sein, dass klar ist, was genau zu tun ist.
Measurable–	messbar; Für jede Aufgabe muss klar sein, wann sie abgeschlossen ist.
Achievable–	machbar; Der Aufgabenempfänger muss in der Lage sein, die Aufgabe umzusetzen – und das kann sich sowohl auf die Person selbst als auch auf die Projektbedingungen beziehen.
Relevant –	relevant; Jede Aufgabe muss sich klar einer User Story zuordnen lassen – so werden z. B. Goldrandlösungen verhindert.
Time-boxed–	zeitlich eingegrenzt; Für jede Aufgabe wird (mindestens) eine klare Deadline benötigt, bis zu der der Task abgeschlossen sein muss.

Sowohl INVEST als auch SMART sind stark entwicklungsorientiert und stellen eher einen Maßstab als ein Vorgehen zum Erstellen von hochqualitativen User Stories dar. Auch das weitverbreitete „Cheat Sheet“ mit Mustern zur User Story-Schneidung (Patterns for Splitting User Stories, siehe [2]) geht in eine ähnliche Richtung.

Aus RE-Sicht und mit Fokus auf ein anwendbares Vorgehen betrachtet, ergibt sich allerdings ein vielversprechender Ansatz. Nähere Informationen zu unseren Erkenntnissen hinsichtlich der Schneidung von User Stories finden Sie in „Eine kleine (User-) Geschichte – Teil I “, „Eine kleine (User-) Geschichte – Teil II “ und „Eine kleine (User-) Geschichte – Teil III “.

Im dritten und letzten Teil der Blogserie zur unterstützenden Technik „User Stories“ lesen Sie, wie Sie mit Abnahmekriterien und durch Hinterfragen von User Stories zusätzliche Informationen zu User Stories herausfinden, die für das Verständnis entscheidend sein können.

Quellen:
[1] http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
[2] http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/