Mehr Softwarequalität: Requirements Engineering

Garbage in – garbage out:

Wie das Anforderungsmanagement die

Softwarequalität beeinflusst

iks Thementag

„Mehr Softwarequalität – Ausgewählte Themen“

22.05.2014

Autor:

Jörg Vollmer

Seite 3 / 76 Garbage in - garbage out: Wie das Anforderungsmanagement die Softwarequalität beeinflusst

Was stört Sie im IT-Alltag am meisten?

Befragt wurden 142 Software-Entwickler:

1. Unklare Anforderungen 51.41 %

2. Zu häufig & schnell wechselnde Anforderungen 37.32 %

3. Termindruck => Quick & Dirty 30.99 %

4. Schlechtes Projektmanagement 28.87 %

5. Unverständlicher Code (z.B. hist. gewachsen) 28.17 %

6. Geringe oder fehlende Testabdeckung 28.17 %

7. Unzureichende Kommunikation im Team 25.35 %

8. Ineffektive (Entwicklungs-) Prozesse 21.13 %

9. Unnötige Meetings & Diskussionen 15.49 %

10. Nicht machbare Aufwandsschätzungen 14.79 %

Quelle: http://umfrage.clean-coder.de (Stand 14. Okt. 2013)

http://umfrage.clean-coder.de




Unklare Anforderungen (51.41%)

Requirements Engineering = Unklare Anforderungen beseitigen!

Konstruktive Maßnahmen

– Welche Fertigkeiten des RE helfen dabei?

– Sieben typische Fallen beim RE

– Welchen Einfluss haben Werkzeuge auf das RE?

Analytische Maßnahmen

– Kann das RE selbst qualitativ und quantitativ bewertet werden?

– Wie lässt sich RE-Qualität messen und sichern?

– Wirkt sich RE-Qualität auf die Software-Qualität aus?


Agenda

Anforderungen aufnehmen

Dokumentieren von Anforderungen

Der Effekt von Akzeptanztests

Anforderungen vermessen und validieren

Verwalten von Anforderungen

Zusammenfassung


Agenda






Zusammenfassung


Aufgaben zum Projektbeginn

Eine initiale Bestandsaufnahme des Projektumfelds ist

unverzichtbar

– Auch im agilen Umfeld

Wichtige Aufgaben sind

– Ziele des Produkts und dessen Nutzen ermitteln

– Ermitteln aller Stakeholder

– Systemkontext und -grenzen bestimmen

– Qualitätsanforderungen identifizieren

… denn sonst bleiben sie unklar Unklare Anforderungen!


Beobachtungstechniken

Apprenticing: Der RE wird wie ein Lehrling eingearbeitet

Der RE lernt hierbei den Fachjargon kennen

Arbeitsschritte hinterfragen und ineffiziente Prozesse entdecken! ...

Die (neue) Software ist eng mit den Geschäftsprozessen verwoben


Falle 1

Ineffiziente Meetings


Unnötige Meetings & Diskussionen

Der RE sollte wissen:

– Jede Debatte, die nicht in fünf Minuten beigelegt werden kann,

kann nicht durch Debattieren gelöst werden (Kent Beck)

– Selbstdarsteller machen andere ratlos und stumm

– Häufig geht es dann nicht mehr um die beste Lösung

Moderationstechniken anwenden

Risiko von falschen Entscheidungen Software-Qualität

s. auch [bdw]


Falle 2

Faule Kompromisse


Unzulässige Verallgemeinerungen

Stakeholder A:

– Bei einem Fehler muss das System anhalten

Stakeholder B:

– Bei einem Fehler muss das System neustarten

RE einigt sich mit A und B auf

– Im Fehlerfall wird eine Ausnahmeroutine veranlasst

Fauler Kompromiss!

Eine Mehrdeutigkeit in einem Anforderungsdokument steht oft

für einen Konflikt bei den Stakeholdern (de Marco)


Falle 3

Designfehler bei Geschäftsobjekten


Das Auto soll verschiedene Farben haben

Was der RE verstand:

Was der Kunde wollte:


Unterschiede ziehen sich durch alle Schichten

Datenbank

Datenmodell

Service-Schicht

Benutzeroberfläche

Fachobjekte und deren Beziehungen identifizieren (DDD)

Hohe Korrekturkosten ↔ es geht auf Kosten der Softwarequalität


Falle 4

Unklare Fachbegriffe


Unklare Fachbegriffe

Was meinte der Banker mit „Engagement“?

– Meinte er persönlichen Einsatz oder

– doch eine vertragliche Verpflichtung wie beim Theater?

Wikipedia

– Risiko bzw. Chance eines Kursverlusts oder -gewinns

Die Fachabteilung

– Das, was die Bank verliert, wenn der Kunde bankrott ist

Fachbegriffe analysieren, Glossar, ubiquitäre Sprache


Best Practices

Überprüfen Sie:

– Wurden Ihre Prozesse jemals untersucht und hinterfragt?

– Verlaufen Ihre (RE-) Meetings effizient und effektiv?

– Welche Stakeholder-Konflikte behindern Entscheidungsfindungen?

– Sprechen alle Stakeholder eine gemeinsame Fachsprache?

– Existiert ein Glossar?


Agenda






Zusammenfassung


Anforderungen dokumentieren

Anforderungen aufschreiben, das kann doch jeder

Aber: Meinungen zu bestehender Dokumentation

– Versteht nur der, der‘s geschrieben hat

– Ist nicht mehr aktuell

– Die kniffligen Sonderfälle fehlen

– Bis man dort die richtige Stelle findet

– Das Wichtigste ist die Telefonliste von Ansprechpartnern

→ Sehr viel Dokumentation wird gar nicht erst gelesen!


Nichts Halbes, nichts Ganzes


Wie entsteht gute (Anforderungs-) Dokumentation?

Es empfiehlt sich die Verwendung

einer Standardgliederung / Template

– RUP

– IEEE 830

– V-Modell

– Volere

Einleitung Zweck,

Stakeholder

Referenzen

Übersicht Systemumfeld

Architektur

Benutzer

Randbedingungen

Anforderungen Funktionalität

Qualitätsanforderungen

Abnahme Akzeptanzkriterien

Testszenarien

Anhang Glossar

Index


Dokumentation in Form von Prosatext

Vorteile

– Wird von allen Beteiligten „verstanden“

– Kein Stakeholder muss eine neue Notation erlernen

– Themenunabhängig universell einsetzbar

Nachteile

– Mehrdeutigkeit leicht möglich

– Kann je nach Kontext verschieden interpretiert werden

– Es gehört zum guten Ausdruck, die Wortwahl zu variieren

Missverständnisse


Falle 5

Unverständliche Formulierungen


Negativbeispiel

Auszug aus einer Spezifikation:

– Funktionalität

In einer „Übersicht“ über alle noch nicht zugeordneten

Geschäftspartner werden alle Geschäftspartner aller Mandanten

ungleich Mandant 0 angezeigt, die bisher keinem Geschäftspartner im

Mandanten 0 zugeordnet wurden. …

Satzstruktur zu komplex


Falle 6

Versteckte Annahmen


Negativbeispiel

Auszug aus einer Spezifikation:

– Funktionalität

In einer „Übersicht“ über alle noch nicht zugeordneten

Geschäftspartner werden alle Geschäftspartner aller Mandanten

ungleich Mandant 0 angezeigt, die bisher keinem Geschäftspartner

im Mandanten 0 zugeordnet wurden. …

Fragen:

– Was ist die „Übersicht“?

– Wo befindet sich diese?

– Wer ordnet was wem zu?

– Was ist Mandant 0?

– Was bedeutet „im Mandanten“ sprachlich?


Das Sophist-REgelwerk

Passiv unterschlägt den Täter

– Beispiel: Ein Auftrag kann storniert werden

– Frage: Von wem? Von jedem, immer?

Analyse des Prozesswortes

– Beispiel: Das System zeigt das Ergebnis nach der Berechnung an

– Prozesswort ist „anzeigen“. Fragen: Wem, Wie, Wann, Warum, …

Vergleiche und Steigerungen

– Beispiel: Die GUI muss schneller reagieren als beim Altsystem

– Frage: Um wie viel schneller? Ist eine Millionstel Sek. auch gültig?

… etc.


Vorschlag: Satzschablonen

Beispiel: Die User-Story

Agile Methoden verwenden sog. User-Stories

Aufbau:

– As a <role> I want <goal/desire> so that <benefit>

– Als ein Autor will ich meine Präsentation speichern können,

damit ich nicht noch einmal alles eingeben muss

Das „damit“ hinterfragt den Geschäftswert

Man beantwortet somit das „Wer“, „Was“ und „Warum / Wozu“


Formale Spezifikationen, Modelle

Beispiele: ER-Diagramme, UML, BPEL, BPMN, DSLs,…

Vorteile

– Sind eindeutiger und aussagekräftiger

– Kompaktere übersichtliche Darstellung

– Für den geübten Leser verständlicher

– Der Implementierung bereits viel näher

– Zum Teil lässt sich Code daraus generieren

Nachteile

– Sind nicht universell einsetzbar

– Syntax / Semantik muss vom Leser verstanden bzw. erlernt werden

– Zusätzliche Tools müssen erlernt werden evtl. Schulungen


Die Mischung beider ergänzt sich positiv

Vorteile

– Modelle können durch natürlich-sprachliche Ergänzungen

verständlicher werden

– Prosatext kann durch Modelle eindeutiger und exakter werden

Beispiel: Mathematische Texte

– Aus jeder nicht-negativen reellen Zahl lässt sich die Wurzel ziehen

–

Häufig verschwindet die (Beweis-) Idee hinter der Abstraktion


Beispiel


Funktionale Anforderungen – Prosa

Der Nikolaus verteilt am 6.12. eines jeden Jahres Geschenke an Kinder

Die Geschenke sind unterschiedlich viel wert

Jedes Kind bekommt ein oder mehrere

Geschenke

Ziel: Der Summenwert der Geschenke soll

für jedes Kind möglichst gleich sein

Aufgabe: Eine Software soll bei Eingabe der

Kinderzahl und der Geschenkwerte eine gerechte Verteilung berechnen


Funktionale Anforderungen – Illustriert

≈ + ≈ + +

…

…


Funktionale Anforderungen – Formal

Voraussetzung

– Gegeben seien natürliche Zahlen

– und eine Preisfunktion .

Aufgabe

– Finde eine Partitionierung , sodass

minimal wird, wobei .

Geschenke Kinder

Gesamtgeschenkwert beim Kind n


Abnahme: Der Nikolaus testet und … Abnahme: … war nicht ganz glücklich.


Warum?

Version 0.9

– Die Lösungen waren anfangs z.T. völlig falsch.

• Der Entwickler hatte die Idee hinter der Formel zunächst nicht ganz

verstanden.

Version 1.0

– Die Verteilung der Geschenke gefiel dem Nikolaus gar nicht:

• Manche Kinder bekamen viele „wertlose“ Geschenke.

• Die Geschenke sollten sich doch möglichst gleich verteilen!

Version 1.1

– Der katastrophale Fall „Kinderheim“:

• 50 Geschenke, 20 Kinder:

• Die Anwendung antwortet nicht mehr!


Falle 7


Erkenntnis

Selbst eine vollständige

und widerspruchsfreie

Spezifikationen garantiert

keine gute Software!

Doch wie lässt sich das

Problem bekämpfen?


Specification by Example

Zwei Kinder, 6 Geschenke im Wert von 1, 2, 2, 4, 6, 9 Euro

– Lösung: 2 + 4 + 6 = 12 = 1 + 2 + 9

– Ungültig: 1 + 4 + 6 = 11 < 13 = 2 + 2 + 9

Zwei Kinder, 6 Geschenke im Wert von 1, 2, 2, 4, 5, 9 Euro

– Lösung: 2 + 4 + 5 = 11 < 12 = 1 + 2 + 9

Zwei Kinder, 10 Geschenke im Wert von 1, 1, 1, 1, 1, 1, 1, 1, 4, 4 Euro

– Lösung: 1 + 1 + 1 + 1 + 4 = 8 = 1 + 1 + 1 + 1 + 4

– Schlecht: 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 = 8 = 4 + 4

20 Kinder, 50 Geschenke im Wert von jeweils 1 Euro

– Lösung: 10 Kinder: 1 + 1, 10 Kinder: 1 + 1 + 1 usw. …


Klassisch: Stille Post

Klassisches Vorgehen:

Kunde Requirements Engineer

Der RE abstrahiert und formuliert eine Spezifikation

Entwickler Software

Tester Testfälle

Kunde Abnahme

anhand von Beispielen

anhand der Spezifikation

anhand der Spezifikation

anhand von Akzeptanzkriterien


Idee des Acceptance Test Driven Development

Beispiele Tests

Anforderungen

werden zu

verifizieren reflektieren


Wer schreibt Akzeptanztests?

RE und Entwickler erstellen zusammen Akzeptanztests

Diese werden in natürlicher Sprache verfasst

Vorrangiges Ziel ist ein gemeinsames Verständnis der Anforderung!

Schön wäre ein einheitliches Format (Satzschablone)…

...mit dem Ziel, daraus Test-Code generieren zu können

Dies ist die Idee das sog. Behavior Driven Development (BDD)


Angenommen … falls … dann …

Ergänzend zur User-Story werden sog. Scenarios formuliert (zusammen bilden sie ein sog. Feature)

User Story

Als ein Nikolaus

will ich dass meine Geschenke an Kinder gerecht verteilt werden,

um Enttäuschungen der Kinder zu vermeiden.

Scenario1: Zwei Kinder, vier Geschenke

Angenommen Nikolaus gibt »2« beim Feld Kinder ein,

und Nikolaus gibt »1, 2, 3, 4« beim Feld Geschenke ein.

Falls Nikolaus auf Rechnen drückt,

dann muss im Feld Ergebnis erscheinen:

»Kind 1: 1 + 4, Kind 2: 2 + 3«


Beispiel mit JBehave

Die Datei nikolaus.story:

Die Test-Klasse:

Given Nikolaus gibt 2 beim Feld Kinder ein Given Nikolaus gibt 1,2,3,4 beim Feld Geschenke ein When Nikolaus auf Rechnen drueckt Then muss im Feld Ergebnis erscheinen: Kind 1: 1 + 4 = 5, Kind 2: 2 + 3 = 5

@Given("Nikolaus gibt $kinder beim Feld Kinder ein") public void eingabeKinder(int kinder) { this.kinder = kinder; } @Given("Nikolaus gibt $geschenke beim Feld Geschenke ein") public void eingabeGeschenke(List<Integer> geschenke) { this.geschenke = geschenke; } @When("Nikolaus auf Rechnen drueckt") public void rechnenDruecken() { rechner = new Rechner(kinder, geschenke); solution = rechner.calculate(); } @Then("muss im Feld Ergebnis erscheinen: $ergebnis") public void dasErgebnisMussSein(String ergebnis) { String loesung = rechner.solutionToString(solution); Assert.assertEquals(ergebnis, loesung); }

s. auch [JBehave]

und [Cucumber]


Beispiel mit JBehave

Die Log-Datei im Erfolgsfall:

Die Log-Datei im Fehlerfall:

Running story com/javacook/nikolaus/nikolaus.story Scenario: Given Nikolaus gibt 2 beim Feld Kinder ein Given Nikolaus gibt 1,2,3,4 beim Feld Geschenke ein When Nikolaus auf Rechnen drueckt Then muss im Feld Ergebnis erscheinen: Kind 1: 1 + 4 = 5, Kind 2: 2 + 3 = 9 (FAILED) (org.junit.ComparisonFailure: expected:<... 5, Kind 2: 2 + 3 = [9]> but was:<... 5, Kind 2: 2 + 3 = [5]>)

Running story com/javacook/nikolaus/nikolaus.story Scenario: Given Nikolaus gibt 2 beim Feld Kinder ein Given Nikolaus gibt 1,2,3,4 beim Feld Geschenke ein When Nikolaus auf Rechnen drueckt Then muss im Feld Ergebnis erscheinen: Kind 1: 1 + 4 = 5, Kind 2: 2 + 3 = 5


Vergleich der Entwicklung: klassisch & BDD

Kunde wird interviewt

RE spezifiziert Anforderungen

Implementierung

QA testet

Auslieferung & Abnahme

Kunde wird interviewt

RE spezifiziert Anforderungen

RE & Entwickl. → Akzeptanztest

Implementierung

QA & autom. Akzeptanztests

Auslieferung & Abnahme


Fazit

Das Erstellen von Akzeptanztests erzwingt eine detailliertere

Auseinandersetzung bereits zu Beginn

Es fördert die Kommunikation zwischen Auftraggeber, RE

und Entwicklung

Es entstehen (nebenbei) automatisierte Tests,

die das System unmissverständlich dokumentieren


Best Practices

Überprüfen Sie (stichprobenartig) einige Anforderungsdokumente

– Sind die Dokumente auffindbar, versioniert?

– Sind die Dokumente einheitlich strukturiert?

– Ist der Text (auch für Uneingeweihte) klar und verständlich?

– Wurden formale Methoden verwendet?

– Enthalten sie Akzeptanzkriterien?

– Sind in Ihren Dokumenten ausreichend Musterfälle enthalten?


Agenda






Zusammenfassung



Warum?

– Anforderungsdokumente sind häufig Grundlage für Verträge

– Einen Qualitätsstandard sicherstellen

– Qualität der Anforderungen wirkt sich auf die Software-Qualität aus

– Fehler & Mängel frühzeitig zu finden, denn…


Kosten von RE-Fehlern bezogen auf Projektphasen


Qualitätsmerkmale für Anforderungen

Wann ist eine Anforderungsspezifikation gut?

– Aktualität (insb. Kundenwunsch-konform)

– Eindeutigkeit

– Widerspruchsfreiheit

– Identifizierbarkeit

– Vollständigkeit

– Änderbarkeit

– Prüfbarkeit

– Realisierbarkeit

– Verständlichkeit


Konkrete Qualitätsmetrik

nach [RuppSoph]

Prozessworteindeutigkeit in Satz i

Bezugspunkteindeutigkeit in Satz i

Begriffseindeutigkeit in Satz i

Eindeutigkeit

Anzahl aller Sätze


Review-Prüfmethoden

Stellungnahme

– Eine weitere Person (am besten fachfremd) wird gebeten,

das Dokument zu prüfen

Inspektion

– Sehr strenger aufwändiger Prozess mit vielen Beteiligten

(Moderator, Prüfer, Termine, Checklisten, Abschlussbericht)

Walkthrough

– Leichtgewichtiges Review (Autor trägt vor, Prüfer, Protokollant)

Automatisiert durch Tools

– Befindet sich in der Forschung


Prüfungsnachbereitung

Ergebnisse standardisiert dokumentieren

Bei Unterschreitungen der Toleranzgrenze

– Ursachen bestimmen!

– Prozesse anpassen

– Evtl. nachschulen


Bezug zur Software-Qualität (exemplarisch)

Funktionalität Korrektheit Wartbarkeit

Aktualität x

Eindeutigkeit x

Widerspruchsfreiheit x

Identifizierbarkeit x

Vollständigkeit x

Änderbarkeit x

Prüfbarkeit x x

Realisierbarkeit x

Verständlichkeit x x

...


Best Practices

Werden Qualitätsprüfungen bzgl. der Anforderungen bei

Ihnen durchgeführt?

– Planen Sie den Prozess sorgfältig und passen ihn gezielt

auf Ihre Bedürfnisse an

– Qualitätsprüfungen sind bislang noch nicht die Regel

– Tun Sie es, nutzen Sie den Vorsprung!


Agenda






Zusammenfassung


Anforderungen verwalten

Ist eine Hauptaufgabe des agilen RE!

Wird umso wichtiger, je

– mehr Anforderungen zu verwalten sind

– mehr Stakeholder auf die Informationen zugreifen

– mehr Änderungen zu erwarten sind

– länger das Produkts (erwartungsgemäß) in Betrieb ist

Die Wahl des(r) richtigen Tools bringt entscheidende Vorteile

Entscheidend für das Software-Qualitätsmerkmal Wartbarkeit


Erwartungen an ein Management-Tool

Notwendige Eigenschaften:

– Anlegen, Ändern, Löschen von Anforderungen

– Strukturierbarkeit

– Gute Suchmöglichkeiten

– Versionsverwaltung / Versionierung

– Einfache Handhabung von Grafiktypen

– Verfolgbarkeit (Traceability)

Wünschenswert

– Konfigurierbarkeit von Eingabemasken und Workflow

– Benutzer- und Rechteverwaltung

– Automatische Analyse von Texten…


Tools

Word & Excel: immer noch üblich

– Grund: Wird von jedem beherrscht

Im Kommen: Issue-Tracker & Wikis

– Grund: Einfaches Erlernen, einfache Bedienung

– Offen für den Aufbau einer Werkzeugkette (!)

Auswahl verschiedener RE-Tools (alphabetisch):

– Caliber RM Contour Cradle

– DESIRe DOORS Enterprise Architect

– HP Quality Center IrQA Lotus Notes

– OptimalTrace ProR RequisitePro

– YAKINDU …

[VolereTools] enthält eine weitaus größere Übersicht


Traceability – so wichtig und doch kaum vorhanden

Typische Wartungsaufgabe:

– Im Risiko-Report vom 31.3 stimmt das Ausfalldatum nicht

Findet der Entwickler folgende Informationen effizient?

– Woher stammt das Datum (Eingabe, Import)?

– In welchen Klassen wird es verarbeitet?

– Welche Datenbankfelder sind involviert?

– Welche fachlichen Abhängigkeiten gibt es zu anderen Daten?

– Wie groß sind die Risiken von Änderungen?

– …


Ideale Welt

RE-Tool

Suchergebnis

Source

Verarbeitung

Lösung

RE-Tool

Anforderung

RE-Tool

"Ausfalldatum"

Modellierung

Fachklassen


Die Realität

Source DB-Tool

Source-Code-Analysen können das zig-fache an Zeit kosten!

Word


Vision: Traceability innerhalb der Werkzeugkette

Anforderungs-

management IDE

Projekt-

management

Build-

Management

Issue Tracking

Modellierung

Persistenz

Delivery

Collaboration

BP-

Management

Monitoring

Configuration-

Management


Best Practices

Prüfen Sie, ob bei Ihnen die passenden Werkzeugkette

im Einsatz ist

Erwägen Sie eine Neuanschaffung:

– Nehmen Sie sich Zeit für die richtige Wahl

– Lassen Sie sich von Experten beraten

– Planen Sie auch den Einsatz von Schulungen


Agenda






Zusammenfassung


Warum ist RE wirtschaftlich?


Zusammenfassung

Einsparungen beim RE bewirken wenig Qualität bei hohen Kosten!

Eine gute Anforderungsanalyse erfordert spezielle RE-Fertigkeiten

– Mit direkten Auswirkungen auf die Softwarequalität

Gute Dokumentation erfordert Talent, Technik und Disziplin

– Sprachkonventionen, Modelle, neue Verfahren (BDD)

– Ziel: Formales und systematisches Vorgehen

– Gute RE-Management-Tools helfen nennenswert

Auch Anforderungen lassen sich qualitätsprüfen

– Ziel: Qualitätssteigerungen durch kontinuierliches Messen

– Qualität bei den Anforderungen Software-Qualität


Referenzen

[RuppSoph]

Chris Rupp, die SOPHISTen; Requirements-Engineering und –

Management, 5. Auflage, Hanser, 2009, ISBN: 978-3446418417

[VolereTools]

http://www.volere.co.uk/tools.htm

[Cucumber]

http://cukes.info

[Jbehave]

http://jbehave.org

[bdw]

http://www.bild-der-

wissenschaft.de/bdw/bdwlive/heftarchiv/index2.php?object_id=32911270




http://cukes.info/

http://cukes.info/

http://cukes.info/

http://jbehave.org/

http://jbehave.org/

http://www.bild-der-wissenschaft.de/bdw/bdwlive/heftarchiv/index2.php?object_id=32911270






Weiterführende Literatur

Klaus Pohl, Chris Rupp; Basiswissen Requirements Engineering;

2. Auflage, Dpunkt Verlag, 2010, ISBN: 978-3898646130

S. Robertson, J. Robertson; Mastering the Requirements Process;

Addison Wesley, 1999, ISBN: 978-0201360462

U. Vigenschow, B.Schneider, I. Meyrose; Soft Skills für Softwareent-

wickler; 2. Auflage, Dpunkt Verlag, 2010, ISBN: 978-3898646710

Rainer Gerlich; 111 Thesen zur erfolgreichen Softwareentwicklung;

1. Auflage, Springer, 2005, ISBN: 978-3540209102


Weiterführende Literatur

Mr. Malcolm Tredinnick, Behaviour Driven Development,

http://www.youtube.com/watch?v=XXHknWKuG2U

Gojko Adzic; Bridging the Communication Gap: Specification by Example

and Agile Acceptance Testing;

Neuri Limited, 2009, ISBN: 978-0955683619

Gojko Adzic; Specification by Example: How Successful Teams Deliver

the Right Software;

Manning, Juni 2011, ISBN: 978-1617290084

http://www.youtube.com/watch?v=XXHknWKuG2U


Folie 9: http://openclipart.org/image/800px/svg_to_png/169415/discussion.png

http://openclipart.org/image/800px/svg_to_png/169418/go-round.png

Folie 13: http://www.clker.com/cliparts/7/1/a/f/11949851591518961590dodge_neon_green_ganson.svg.med.png

Folie 19: http://www.clker.com/clipart-15442.html

Folie 29: http://upload.wikimedia.org/wikipedia/commons/thumb/d/d0/Lage-_und_Verhältnisbestimmung_Zahn.jpg/

800px-Lage-_und_Verhältnisbestimmung_Zahn.jpg

Folie 32: http://openclipart.org/detail/1956/santa-and-his-bag-by-johnny_automatic

Folie 33: http://www.wpclipart.com/people/children/girls/girls_3/girl_with_pigtails.png.html

http://www.wpclipart.com/people/children/boys/little_boy.png.html

http://www.wpclipart.com/holiday/Christmas/gifts/gift_box_silver.png.html

http://www.wpclipart.com/holiday/Christmas/gifts/gift_black.png.html

…

Bildernachweise

http://openclipart.org/image/800px/svg_to_png/169415/discussion.png




http://www.clker.com/cliparts/7/1/a/f/11949851591518961590dodge_neon_green_ganson.svg.med.png

http://www.clker.com/clipart-15442.html














http://openclipart.org/detail/1956/santa-and-his-bag-by-johnny_automatic






















Folie 33: http://www.wpclipart.com/holiday/Christmas/gifts/gifts_w_tags.png.html

http://www.wpclipart.com/holiday/Christmas/gifts/gift_box_blue_ribbon/package_blue_ribbon_and_blue.png.html

http://www.wpclipart.com/holiday/valentines/candy_and_gifts/valentine_gift_box.png.html

Folie 38: http://www.doktoranden-netz.de/Idee.GIF

Folie 55: http://openclipart.org/detail/29647/quality-control:-rejected-by-stijnbern

Folie 63: http://docs.typo3.org/flow/TYPO3FlowDocumentation/_images/DomainModel-2.png

Folie 64: http://openclipart.org/image/800px/svg_to_png/94723/db.png

Sämtliche hier nicht aufgeführte Bilder bzw. Grafiken wurden vom Autor selbst erstellt.

Bildernachweise












http://openclipart.org/image/800px/svg_to_png/29641/1267371838.png


















http://www.rottenplaces.de/

http://www.rottenplaces.de/


Abkürzungen

ATDD Acceptance Test Driven Development

BDD Behavior Driven Development

BPEL Business Process Execution Language

BPMN Business Process Model and Notation

DDD Domain-Driven Design

DSL Domain-Specific Language

ER Entity Relationship

QA Quality Assurance

QS Qualitätssicherung

RE Requirements Engineering bzw. Requirements Engineer

TDD Test-Driven Development

UML Unified Modeling Language

Fragen?

www.iks-gmbh.com

Technology

Mehr Softwarequalität: Requirements Engineering