Mehr Softwarequalität: Requirements Engineering

Garbarge in - garbage out:
Wie das Anforderungsmanagement die
Softwarequalität beeinflusst
iks Thementag
„Mehr Softwarequalität – Ausgewählte Themen“
23.04.2013
Autor:
Jörg Vollmer

Seite 3 / 75Garbarge in - garbage out: Wie das Anforderungsmanagement die Softwarequalität beeinflusst
Was stört Sie im IT-Alltag am meisten?
Befragt wurden 103 Software-Entwickler:
1. Unklare Anforderungen 50.49 %
2. Zu häufig & schnell wechselnde Anforderungen 40.78 %
3. Schlechtes Projektmanagement 29.13 %
4. Geringe oder fehlende Testabdeckung 28.16 %
5. Unzureichende Kommunikation im Team 27.18 %
6. Termindruck => Quick & Dirty 24.27 %
7. Unverständlicher Code 21.36 %
8. Unnötige Meetings & Diskussionen 19.42 %
9. Ineffektive (Entwicklungs-) Prozesse 18.45 %
10. Schlechte Teamstimmung 15.53 %
Quelle: http://www.clean-code.info/umfrage

Unklare Anforderungen (50.49%)
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

Aufgaben zum Projektbeginn
Eine initiale Bestandsaufnahme des Projektumfelds 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 (Platz 8)
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

Ein Auto kann 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 Ihrer 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 eine Spezifikation:
– Funktionalität
In einer „Liste“ über alle noch nicht zugeordneten Kunden werden alle
Kunden aller Typen ungleich Typ 0 angezeigt, die bisher keinem
Kunden vom Typ 0 zugeordnet wurden. …
Satzstruktur zu komplex

Falle 6
Versteckte Annahmen

Negativbeispiel
Auszug aus eine Spezifikation:
– Funktionalität
In einer „Liste“ über alle noch nicht zugeordneten Kunden werden alle
Kunden aller Typen ungleich Typ 0 angezeigt, die bisher keinem
Kunden vom Typ 0 zugeordnet wurden. …
Fragen:
– Was ist die „Liste“
– Wo befindet sich diese?
– Wer ordnet was wem zu?
– Was ist Typ 0?

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
– yxxyyx  2
:0giltDannIR.,seienEs
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
bei jedem 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 .
},...,1{
...,,1
nN
mi
i 



0 mn
NI},...,1{: np
)()(max
mji1
jPiP 



iNk
kpiP )(:)(

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 gleichmäßig 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 ein 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
verifizierenreflektieren

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«

Bespiel 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:
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:
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ätsmetriken
1wobei,100
#


 wvu
gssätzeAnforderun
BEwBPEvPEu
eitEindeutigk
sindtbeantworteJAmitzuFragenallefalls,1
sonst,0)(),(),( iA
iii ABEABPEAPE 
tndeutigkeiBegriffsei
keitteindeutigBezugspunk
keitteindeutigProzesswor



BE
BPE
PE
nach [RuppSoph]

Review-Prüfmethoden
Stellungnahme
– Eine weitere Person 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 ist außerordentlich wichtig!
Entscheidend für das Software-Qualitätsmerkmal Wartbarkeit

Erwartungen an ein Management-Tool
Notwendige Eigenschaften:
– Anlegen, Ändern, Löschen von Anforderungen
– Strukturierbarkeit (hierarchisch, verlinkbar)
– Gute Suchmöglichkeiten (Volltext, unscharf, Stichwörter)
– Versionsverwaltung / Versionierung
– Einfache Handhabung von Grafiktypen (Einfügen, Bearbeiten)
– 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: Jira & Wikis
– Grund: Einfaches Erlernen, Einfache Bedienung
– Offen für den Aufbau einer Werkzeugkette
Auswahl verschiedener RE-Tools (alphabetisch):
– Caliber RM Contour Cradle
– DOORS DESIRe Enterprise Architect
– HP Quality Center IrQA Lotos Notes
– OptimalTrace ProR RequisitePro
– YAKINDU …
[VolereTools] enthält eines 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
X

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, so
– 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

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

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

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 55: http://openclipart.org/detail/29647/quality-control:-rejected-by-stijnbern
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

Abkürzungen
ATDD Acceptance Test Driven Development
BDD Behavior Driven Development
BPE 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

Mehr Softwarequalität: Requirements Engineering

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (7)

Ähnlich wie Mehr Softwarequalität: Requirements Engineering

Ähnlich wie Mehr Softwarequalität: Requirements Engineering (20)

Mehr von IKS Gesellschaft für Informations- und Kommunikationssysteme mbH

Mehr von IKS Gesellschaft für Informations- und Kommunikationssysteme mbH (20)

Mehr Softwarequalität: Requirements Engineering