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 / 76Garbage 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)

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
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«

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:
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ä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

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

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

Mehr Softwarequalität: Requirements Engineering

Ähnliche diashows

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Empfohlen für Sie

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ä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