Durchblick im Schablonendschungel – Teil 3

Nachdem wir Ihnen im ersten Teil unserer Blogserie die SOPHIST-Schablone und eine Schablone von Esser & Struss vorgestellt haben, zeigten wir im zweiten Teil eine Schablonen von Alistair Mavin (EARS+), eine der IAG Consulting sowie eine von Jörg Holtmann. Dies alles sind Schablonen für funktionale Anforderungen. Im dritten und letzten Teil unserer Blogserie möchten wir Ihnen eine Schablone für nichtfunktionale Anforderungen vorstellen. Unter dem Namen NoFun (Akronym für Non-Functional Requirements) entwickelten Xavier Franch und Pere Botella eine Pseudo-Sprache für nichtfunktionale Anforderungen.

Weiterlesen

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

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.

Weiterlesen

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

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

User Stories – Ermittlungs- oder Dokumentationstechnik? TEIL I: Die Grundlagen

Den meisten dürfte der Begriff „User Story“ im Zusammenhang mit Agiler Softwareentwicklung bekannt sein, z. B. in Verbindung mit Scrum und agilen Anforderungen. User Stories als reine Dokumentationsform zu bezeichnen, schriftliche Anforderungen, die eben im agilen Umfeld vorkommen, greift allerdings ein Stück zu kurz.Ursprünglich sind User Stories eine Technik aus dem Extreme Programming. Sie stellen mentale Anker dafür da, dass der Kunde ein bestimmtes Feature möchte, und dass über die Details der Umsetzung dieses Features noch diskutiert werden muss. Mike Cohn nennt sie „Kommunikationsversprechen“ (tokens for promising future communication): Sie dienen als Grundlage für Kommunikation, die zu einer Einigung führt, mit der Entwicklungsteam und Kunde einverstanden sind.User Stories können prinzipiell beliebig aufgebaut sein. Zum Beispiel ist „Studenten können ihre Parktickets online kaufen“ genauso eine User Story wie „Als Mitarbeiter möchte ich meine Stunden nach Kategorien eingeben können, damit meine Aufwände transparent werden“. In der Praxis hat sich, unter anderem durch Mike Cohns „User Stories“ [1] und durch die zunehmende Normierung durch zahlreiche Trainingsangebote und Zertifizierungsmöglichkeiten, eine Standardform herausgebildet: Weiterlesen