ACHTUNG: Diese Vorlage nur mit PPT-Versionen ab 2007 verwenden!!

Präsentation zum Thema: "ACHTUNG: Diese Vorlage nur mit PPT-Versionen ab 2007 verwenden!!"—  Präsentation transkript:

1 ACHTUNG: Diese Vorlage nur mit PPT-Versionen ab 2007 verwenden!! Zwar können auch ältere Versionen diese Vorlage lesen, in der Bearbeitung gibt es aber schwerwiegende Probleme u.a. in Hinsicht auf den Folienmaster und auf die Seitenzahlen.

2 iks Thementag „Mehr Softwarequalität – Ausgewählte Themen“ 23.04.2013
Garbarge in - garbage out: Wie das Anforderungsmanagement die Softwarequalität beeinflusst iks Thementag „Mehr Softwarequalität – Ausgewählte Themen“ Ich begrüße Sie zu der Präsentation Garbage-In - Garbage Out - Wie das Anforderungsmanagement die Software-Qualität beeinflusst. Anstatt Anforderungsmanagement verwendet man auch häufig den Begriff Requirements Engineering, und den, der dies tut, nennt man auch den Requirement Engineer, in der Präsentation häuft mal mit RE abgekürzt. Autor: Jörg Vollmer

3 Was stört Sie im IT-Alltag am meisten?
Befragt wurden 103 Software-Entwickler: Unklare Anforderungen % Zu häufig & schnell wechselnde Anforderungen % Schlechtes Projektmanagement % Geringe oder fehlende Testabdeckung % Unzureichende Kommunikation im Team % Termindruck => Quick & Dirty % Unverständlicher Code % Unnötige Meetings & Diskussionen % Ineffektive (Entwicklungs-) Prozesse % Schlechte Teamstimmung % Quelle: Am Anfang des Jahres haben mein Kollege Reik Oberath und ich eine Umfrage durchgeführt. Befragt wurden 103 Softwareentwickler: Was stört sie im IT-Alltag am meisten? Über die Hälfte aller Entwickler beklagen sich über unklare Anforderung. Über 40 % über so häufig und schnell wechselnde Anforderungen. Das hat auch uns in der Tat überrascht.

4 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? Bleiben wir mal bei dem "Platz 1" "Unklare Anforderungen". Wer oder was kann dagegen etwas tun? Eindeutige Antwort: Requirements Engineering, denn Requirements Engineering ist nichts anderes als "unklare Anforderungen beseitigen"; ok, die Dokumentation derer gehört dann im Anschluss auch noch dazu - dazu kommen wir auch. Offensichtlich wird Requirements Engineering zu wenig oder nicht gut genug betrieben. Wir wollen im Folgenden untersuchen, welche Maßnahmen und Best Practices existieren, um diese schlechte Situation zu verbessern. Wir unterscheiden dabei zwischen konstruktiven Maßnahmen und den analytischen. Konstruktive Maßnahmen beruhen auf Erfahrung und dem gesunden Menschenverstand. Zu den konstruktive zählen Dinge wie: 1) Welche Fertigkeiten des RE helfen dabei? 2) Sieben typische Fallen beim RE 3) Welchen Einfluss haben Werkzeuge auf das RE? Bei den analytischen Dingen ergeben sich folgenden Fragestellungen: 1) Kann das RE selbst qualitativ und quantitativ bewertet werden? 2) Wie lässt sich RE-Qualität messen und sichern? 3) Wirkt sich RE-Qualität auf die Software-Qualität aus?

5 Anforderungen aufnehmen Dokumentieren von Anforderungen
Der Effekt von Akzeptanztests Anforderungen vermessen und validieren Verwalten von Anforderungen Zusammenfassung Der Vortrag führt uns durch folgenden Agenda: Wir beginnen mit den konstruktiven Maßnahmen und betrachten zunächst das Aufnehmen, anschließend das Dokumentieren von Anforderungen. Dabei untersuchen wir, welchen positiven Effekt das Erstellen von Akzeptanztests im RE haben kann. Danach kommen wir zu den analytischen Maßnahmen, dem Vermessen und Validieren von Anforderungen Und noch mal zurück zu den konstruktiven Maßnahmen, dem Verwalten von Anforderungen.

6 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 Eine initiale Bestandsaufnahme des Projektumfelds zum Projektbeginn ist unverzichtbar. Dazu gehört: Ziele des Produkts und deren Nutzen ermitteln, denn wir wollen ja nicht nur die Dinge richtig entwickeln, sondern auch die richtigen Dinge entwickeln. Das Ermitteln aller Stakeholder: Da gehören beispielsweise auch die Leute aus dem Betrieb dazu. Es passiert schon mal, dass man während der Entwicklung selbstverständlich von bestimmten Oracle-Features ausgeht und der Betrieb am Schluss sagt: Das unterstützen wir überhaupt nicht. Dann guckt man dumm. Den System-Kontext und Grenzen bestimmen: Gerade bei Schnittstellen zu anderen System ist es wichtig zu wissen, wo die eigene Verantwortung aufhört und die andere beginnt. Schlussendlich ist es wichtig, Qualitätsanforderungen zu identifizieren, denn sonst bleiben Sie unklar, und dann sind wir wieder bei den unklaren Anforderungen! Auch Qualitätsanforderungen sind selbstverständlich Anforderungen. … denn sonst bleiben sie unklar  Unklare Anforderungen!

7 Beobachtungstechniken
Apprenticing: Der RE wird wie ein Lehrling eingearbeitet. Der RE lernt hierbei den Fachjargon kennen Arbeitsschritte hinterfragen und ineffiziente Prozesse entdecken! ... Wenn man als Requirements Engineer ein neues Projekt betritt, ist es sinnvoll, sich erst einmal einen Überblick zu verschaffen. Beim sogenannten Apprenticing wird der RE wie ein Lehrling eingearbeitet. Dabei beobachtet er zurückhaltend den Betrieb und die Mitarbeiter und lernt hierbei schon einmal den Fachjargon kennen. Eine spätere Aufgabe wird sein, eine für alle Stakeholder verständliche Fachsprache zu etablieren. Ein weiteres Ziel seiner Beobachtung ist es, Arbeitsschritte zu hinterfragen und eventuell ineffiziente Prozesse zu entdecken. Denn die neu zu erstellende Software wird eng mit den Geschäftsprozessen verwoben sein. Ist die Planung der neuen Software zu weit fortgeschritten, lassen sich die Geschäftsprozesse nur noch schwer ändern. Kommen wir nun zum anfangs erwähnten „Beseitigen von unklaren Anforderungen“. Die (neue) Software ist eng mit den Geschäftsprozessen verwoben.

8 Ineffiziente Meetings
Falle 1 Ineffiziente Meetings Im letzten Eclipse-Magazin war ein schöner Artikel die beiden Produktivitätskiller. Zum einen sind dies die Fülle an s, zum zweiten „Ineffiziente Meetings“.

9 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 s. auch [bdw] Meetings und Interviews sind immer noch die häufigste Form von Befragungstechniken. Kann sehr produktiv sein, aber auch riskant werden. Kommt drauf an, wer teilnimmt. Ich möchte mit einem Zitat von Kent Beck fortfahren: Jede Debatte, die nicht in 5 Minuten beigelegt werden kann, kann nicht durch Debattieren gelöst werden. Dabei zielte er auf "unnötige Meetings und Diskussionen", was im Übrigen bei unserer Umfrage auf Platz acht steht. Häufig hat man es in Diskussionen auch mit Selbstdarstellern zu tun und dann geht es meist auch nicht mehr um die beste Lösung. Zitat: Die mit den schwächsten Stimmen haben oft die besten Ideen. [Sir Peter Ustinov| In solchen Fällen, muss der RE besondere Moderationstechniken anwenden, was ich aber hier jetzt nicht weiter vertiefen möchte. Darüber könnte man eine separate Präsentation halten. Ich möchte betonen, dass es bei einem schlechtem Diskussionsstil ein hohes Risiko von falschen Entscheidungen gibt, die selbstverständlich einen eklatanten negativen Einfluss auf die Software Qualität haben können. Andere Befragungstechniken: Fragebögen, Selbstaufschreibung, Interviews, Fokusgruppen, Konsensbildung, Workshops, Rollenspiele  Vortrag Requirements Engineering Risiko von falschen Entscheidungen  Software-Qualität

10 Falle 2 Faule Kompromisse Falle 2: Faule Kompromisse.

11 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) Angenommen, ein Stakeholder fordert: "Bei einem Fehler muss das System anhalten." Ein anderer Stakeholder behauptet: "Bei einem Fehler muss das System neustarten." Dann ist das erst mal ein unvereinbarer Konflikt. Der konfliktscheue RE könnte sich nun trotzdem mit beiden einigen, indem er festhält: Im Fehlerfall wird eine Ausnahmeroutine veranlasst. Das ist ein fauler Kompromiss und somit eine unzulässige Verallgemeinerung. Spätestens der Entwickler wird fragen, was genau bei der sog. Ausnahmeroutine zu machen ist. Schlimmstenfalls implementiert der Entwickler, was er sich denkt. Auch schon bei de Marco findet man: Eine Mehrdeutigkeit in einem Anforderungsdokument steht oft für einen Konflikt bei den Stakeholdern.

12 Designfehler bei Geschäftsobjekten
Falle 3 Designfehler bei Geschäftsobjekten Falle 3: Design-Fehler bei Geschäftsobjekten

13 Ein Auto kann verschiedene Farben haben
Was der RE verstand: Was der Kunde wollte: Der RE verstand: Ein Auto kann verschiedene Farben haben. Der Kunde wollte aber, dass ein Auto verschiedene Farben haben kann. Diese Art von Fehlern ist mir schon mehrfach in Projekten begegnet und hat einen durchaus ernsten Hintergrund. Im ersten Fall hat das Objekt Auto ein Attribut „Farbe“, im zweiten Fall gibt es eine 1:n-Beziehung zu Farbe.

14 Unterschiede ziehen sich durch alle Schichten
Datenbank Datenmodell Service-Schicht Benutzeroberfläche  Fachobjekte und deren Beziehungen identifizieren (DDD) Hier noch mal im UML-Diagramm zu erkennen. Es geht um die Kardinalität zwischen Geschäftsobjekten. Das ist Thema des sog. Domaine Driven Designs und behandelt die grundlegende Modellierung der Fachlichkeit. Fehler hierbei ziehen sich durch alle Schichten der Software: von der Datenbank über die Service-Schicht bis hin zur Benutzeroberfläche. Es geht hierbei darum, Geschäftsobjekte und deren Beziehungen untereinander zu identifizieren Solche Fehler erfordern entweder hohe Korrekturkosten, oder es geht auf Kosten der Software Qualität, falls man sich mit einem Workaround zufriedengibt. Hohe Korrekturkosten ↔ es geht auf Kosten der Softwarequalität

15 Falle 4 Unklare Fachbegriffe Falle 4: unklare Fachbegriffe

16 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 Bei meinem letzten Projekt saß ich zusammen mit der Fachabteilung und hörte häufig den Begriff Engagement. Ich kannte den Begriff bislang nur in" der Bedeutung "persönlichen Einsatz" oder einer "vertraglichen Verpflichtung" wie beim Theater. Das konnte hierbei nicht gemeint sein. Als ich bei Wikipedia nachschaute, konnte ich lesen, dass damit im Finanz-Umfeld das Risiko beziehungsweise die Chance eines Kursverlustes oder Gewinns gemeint ist. Das machte aber auch in unserem Kontext keinen richtigen Sinn. Als ich dann mit der Fachabteilung telefonierte, erfuhr ich dass es das ist, was eine Bank verliert, wenn ein Bankkunde bankrott ist. Hätte ich das vorher gewusst, hätte ich vielleicht den Gesprächen folgen können. Aus diesem Grund ist es wichtig, die Fachbegriffe zu analysieren gegebenenfalls in einem Glossar zusammenzufassen und, wie schon vorher erwähnt, eine einheitliche Fachsprache bei allen Stakeholdern zu etablieren. Diese nennt man auch "ubiquitäre Sprache". Auch der Entwickler sollte unbedingt seine Bezeichner dahingehend im Code wählen. (Ein zweites schnönes Beispiel ist das Default-Datum)

17 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? Fassen wir noch einmal zusammen: Wurden ihre Prozesse jemals untersucht und hinterfragt? Verlaufen ihre Meetings effizient und effektiv? Welche Stakeholder-Konflikte, beziehungsweise welches Stakeholder behindern Entscheidungsfindung? Sprechen alle Stakeholder eine gemeinsame Fachsprache? Existiert ein Glossar? Falls dies alles bei Ihnen zutrifft, befinden Sie sich schon bei den oberen 3%.

18 Anforderungen aufnehmen Dokumentieren von Anforderungen
Der Effekt von Akzeptanztests Anforderungen vermessen und validieren Verwalten von Anforderungen Zusammenfassung Kommen wir nun zu den beiden Themen "Dokumentieren von Anforderungen" und "der positive Effekt von Akzeptanz Tests".

19 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 Anforderungen aufschreiben, das kann doch jeder, oder? Im krassen Gegensatz dazu stehen aber die landläufigen Meinungen zu bestehender Dokumentation: Das versteht doch nur der es geschrieben hat. Die ist eh nicht mehr aktuell. Oder die kniffligen Sonderfälle fehlen sowieso. Bis man dort die richtige Stelle findet. Oder das wichtigste ist sowieso die Telefon Liste von Ansprechpartnern. Die Folge davon ist: Sehr viel Dokumentation wird gar nicht erst gelesen! → Sehr viel Dokumentation wird gar nicht erst gelesen!

20 Nichts Halbes, nichts Ganzes
Ich finde, knappe Dokumentation kann sehr nützlich sein in Form von Notizen von Informationen, die ich mir im Kopf nicht merken kann. Das praktiziere ich täglich mit meinem privaten Wiki. Vollständige Dokumentation hat auch einen großen Nutzen, wenn auch ein unbedarfter Leser dort alles findet und verstehen kann. Mein Eindruck ist, dass die meiste Dokumentation sich leider irgendwo in der Mitte befindet. Dies gilt übrigens auch für die meisten Artikel in Fachmagazinen. Demjenigen, der schon mit dem Thema vertraut ist, nützt die Doku nicht viel, weil er eh schon alles weiß. Demjenigen, der noch nichts über das Thema weiß, nutzt die Doku dann auch nichts, weil für ein Verständnis zu wenig Informationen meist in Form von versteckten Annahmen enthalten sind.

21 Wie entsteht gute (Anforderungs-) Dokumentation?
Einleitung Zweck, Stakeholder Referenzen Übersicht Systemumfeld Architektur Benutzer Randbedingungen Anforderungen Funktionalität Qualitätsanforderungen Abnahme Akzeptanzkriterien Testszenarien Anhang Glossar Index Es empfiehlt sich die Verwendung einer Standardgliederung / Template RUP IEEE 830 V-Modell Volere Wie entsteht nun gute Dokumentation? Zunächst empfiehlt es sich unbedingt, eine standardisierte Art der Gliederung zu verwenden. Dafür sind verschiedene Templates vorgeschlagen worden, von denen ich hier einmal vier aufgeschrieben habe. Ob man einer davon verwendet, sei jedem freigestellt. Viel wichtiger finde ich, dass man sich überhaupt auf eine einheitliche Gliederung einigt.

22 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 Die meiste Dokumentation wird unbestritten in Form von Prosatext verfasst. Dies hat die Vorteile, dass es von allen Beteiligten zumindest syntaktisch verstanden wird. Kein Stakeholder muss eine neue Notation erlernen, und sie ist Themen-unabhängig universell einsetzbar. Es hat allerdings die Nachteile, dass eine Mehrdeutigkeit leicht möglich ist und dass ist je nach Kontext verschiedene Interpretationen möglich sind. Weiter gehört das zum guten Ausdruck, die Wortwahl zu variieren was zu Missverständnissen führen kann. Man bekommt schon in der Schule für das Verfassen von Aufsätzen beigebracht, dass es schöner klingt, z.B. nicht immer das Wort Auto zu benutzen, sondern auch mal PKW oder Fahrzeug. Gern zu Verwechslungen kommt es auch bei solchen Dingen wie Auftragsart oder Auftragstyp. Für Dinge ist Prosa auch gar nicht gut geeignet. Versuchen Sie im einmal, nur mit Worten zu beschreiben, wie man einen Winzerknoten knotet.

23 Unverständliche Formulierungen
Falle 5 Unverständliche Formulierungen Eine weitere Falle sind unverständliche Formulierungen.

24 Negativbeispiel Auszug aus eine Spezifikation: Satzstruktur zu komplex
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 Ich habe mir die Erlaubnis eingeholt, den folgenden Ausschnitt aus einem Anforderungs-Dokument zu zitieren. Die Beschreibung der Funktionalität beginnt mit folgendem Satz: 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. Haben Sie das verstanden? Zunächst ist die Satzstruktur viel zu komplex. Aber auch nach dem dritten Lesen ergeben sich viele Fragen:

25 Falle 6 Versteckte Annahmen
Und wir kommen gleich zu der nächsten Falle, den versteckten Annahmen. Hier die Zahnpasta-Story

26 Negativbeispiel Auszug aus eine Spezifikation: Fragen:
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? Nicht erklärt wird beispielsweise was eine Übersicht ist wo befindet sich diese? Wer ordnet auch wem etwas zu dem Mandanten null? Was ist überhaupt der Mandant null? Im gesamten Dokument konnte man dies nicht herausfinden. Dies sind die sog. W-Fragen. Eine Gefahr für den Requirements Engineer besteht auch darin, dass er irgendwann selbst so tief im Thema steckt und somit viele Dinge als selbstverständlich voraussetzt.

27 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. So haben sich die sog. Sophisten, so nennt sich die Mitarbeiter von Chris Rupp, einer bekannten deutschen RE, ein Regelwerk ausgedacht: See schlagen vor, keine passiv setze zu benutzen, denn das Passiv unterschlägt den Täter. Beispiel: ein Auftrag kann storniert werden. Dann bleibt die Frage offen: Von wem? Von jedem, immer? Weiter soll das Prozesswort, also das Verb, analysiert werden. Ein Beispiel ist: Das System zeigt das Ergebnis nach der Berechnung an. Hierbei ist das Prozesswort „anzeigen“ und der Text muss die sog. W-Fragen beantworten. Das sind also Fragen wie: Wem wird das System angezeigt, wie, wann, und vor allem, warum. Und so gibt es noch eine ganze Liste von weiteren Vorschlägen.

28 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“ Der Deutschlehrer mag das ganz gruselig finden, aber das verwenden von Satzschablonen ist für Anforderungsdokumente von entscheidendem Vorteil. Dort schlagen die Sophisten auch grammatisch einfache Struktur vor, ich habe hier mal das Beispiel der sog. User-Story aufgeschrieben. Diese sind sehr beliebt bei den agieren Methoden und haben folgende Struktur: Als ein … will ich … damit … Als ein Autor will ich meine Präsentation speichern können, damit ich nicht noch einmal alles eingeben muss. Das damit hinterfragt den Geschäftswerts, was für die eingehenden wichtig ist dass sie ihre Aufgaben nach der Priorisierung des Geschäftswertes sortieren. Verwendet man diese Satzstruktur beantwortet man automatisch immer das "Wer", das "Was" und das "Warum". Wir werden später auch noch eine andere Satzschablone kennen lernen.

29 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 Aufgrund der Nachteile der Formulierungen in Prosa, haben sich die Informatiker schon seit langem darüber Gedanken gemacht, wie man Anforderungen exakter spezifizieren kann. Dabei herausgekommen sind beispielsweise Entity-Relationship-Diagramme, die UML, die Business-Prozess-Sprachen und die Domänen-spezifische Sprachen. Letztere sind in der letzten Dekade modern geworden und sind eine kleine sehr Eingeschränkte auf eine spezielle Domänen zugeschnittene Sprache. Kennen Sie zum Beispiel 1 4 approxymal, 1 6 distal? Das ist ein Beispiel für eine Domänen spezifische Sprache eines Zahnarztes, die im übrigen international standardisiert ist. Weitere Beispiele sind SQL zur Abfrage von Datenbanken, oder HTML zur Beschreibung von Webseiten. Auch die Notenschrift ist eine Domänen-spezifische Sprachen zur Beschreibung von Musik. Die Vorteile sind offensichtlich: Sind eindeutiger und aussagekräftiger. Sie ermöglichen eine kompaktere und übersichtlicherer Darstellungen, die für den geübten Leser sogar verständlicher ist. Sie ist Implementierung bereits viel näher und zum Teil lässt sich sogar Code daraus generieren. Es gibt natürlich auch Nachteile: Sind nicht universell einsetzbar Syntax / Semantik muss vom Leser verstanden bzw. erlernt werden Zusätzliche Tools müssen erlernt werden, evtl. Schulungen

30 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 Die Mischung beider Methoden ergänzen sich positiv. Beispiele dieser Art findet man häufig bei mathematischen Texten. Auch Mathematikern benutzen eine Mischung aus Prosatext und ihrer Domäne spezifischen Sprache, der Formelsprache, die sich seit Jahrhunderten weltweit bewährt hat. Nehmen wir hier ein Beispiel: Aus jeder nicht-negativen reellen Zahl lässt sich die Wurzeln ziehen. Derjenige, der weiß, was Wurzelziehen ist, braucht sich die Formel nicht mehr anzuschauen. Aber für denjenigen, dem das nicht klar ist, steht noch einmal unmissverständlich die Aussage in Form dieses formalen Ausdrucks. Allerdings gibt es auch hier bei Nachteile: So exakt und kompakt solche formalen Modelle auch sind, für einen ungeübten Leser sind sie doch zum Teil schwer verständlich, und somit auch fehleranfällig. Häufig entdeckt man die Idee nicht mehr hinter der Abstraktionen. Häufig verschwindet die (Beweis-) Idee hinter der Abstraktion

31 Beispiel Wozu das führen kann, möchte ich anhand eines Beispiels erläutern.

32 Funktionale Anforderungen - Prosa
Der Nikolaus verteilt am 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. Ostern ist gerade vorbei, d.h. bald steht der Nikolaus vor der Tür. Dieser hat am 6. Dezember eines jeden Jahres die Aufgabe Geschenke an Kinder zu verteilen. Ich habe versucht bei den folgenden Sätzen, die Vorschläge der Sophisten zu berücksichtigen. Die Geschenke sind unterschiedlich viel wert. Jedes Kind bekommt einen oder mehrere Geschenke. Ziel dabei ist das der Summenwert der Geschenke bei geben Kind möglichst gleich sein soll. Sehen Sie wo die Hauptschwäche bei dieser Anforderung liegt? Sie liegt in den beiden Wörtern möglichst gleich.

33 Funktionale Anforderungen – Illustriert
+ + ≈ + ≈ … Ein Bild sagt mehr als 1000 Worte. Vielleicht hilft ja diese Grafik weiter? Aber auch hier ist das Problem des ungefähr nicht gelöst. …

34 Funktionale Anforderungen - Formal
Voraussetzung Gegeben seien natürliche Zahlen und eine Preisfunktion Aufgabe Finde eine Partitionierung , sodass minimal wird, wobei Also entschied sich der RE, dies formal exakt zu beschreiben. Ich möchte gar nicht mal, dass Sie dies auf Anhieb verstehen und dies auch gar nicht ganz im Detail erläutern, nur kurz zur Idee: Das Groß-P ist jeweils der Summenwert der Geschenke, den das i-te Kind erhält. Dieser Ausdruck verlangt, dass die ungerechte Differenz der Geschenkwerte zwischen jeweils zwei Kinder möglichst klein wird, wobei hier jedes Kind mit jedem verglichen wird. Das klingt ganz gut oder?

35 Abnahme: Der Nikolaus testet und war unglücklich…
Die Software wurde dann vom Entwickler implementiert, hier das Ergebnis: Nun testete der Nikolaus einige Fälle durch und war nicht so recht zufrieden. Was war passiert?

36 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! Die Beta-Version ging sofort zurück, da die Lösungen zum Teil falsch, was daran lag, dass der Entwickler die die Idee hinter der Formel zunächst nicht ganz verstanden, und so schlichen Fehler ein. Nach einem Gespräch mit dem RE ging dem Entwickler dann ein Licht auf, und es kam zur Version 1.0, die die Formel korrekt umsetzte. Der Nikolaus war aber immer noch nicht glücklich. Angeblich bekamen manche Kinde viele wertlose Geschenke, während andere die teureren bekommen. Weiter an den Entwickler geleitet, sagte dieser: "Kann ich mir nicht vorstellen, nenn mal ein Beispiel!" "Nenn mal ein Beispiel" - ich möchte, dass Sie sich das mal im Hinterkopf behalten, das kommen wir gleich noch mal zu. Angenommen, ich hab nur zwei Kinder, wenn ich acht mal die 1 eingibt, und zweimal die 4, dann erhält das eine Kind acht minderwertige Geschenke und das andere zwei hochwertige. Ok, die Summe ist bei beiden acht, aber ich sagte doch, dass die Geschenke sich gleichmäßig verteilen sollen, und damit meine ich, dass beide Kinder ein 4-Euro-Geschenk bekommen und 4 Ein-Euro Geschenke. Das ist nun aus RE-Sicht ein interessanter Fall, denn das ist eine verstecke Annahme des Nikolaus, die der RE anscheinend nicht mitbekommen und bedacht hat! Aber auch das ließ sich nachbessern, dabei wurde die Formel noch komplizierter, und es kann zur Version 1.1. Nun geschah das Schlimmste. Es war der 6.12, der Nikolaus kam bei einemKinderheim vorbei und wollte den 20 Kindern 50 Geschenke mitgeben. Was geschah: Die Anwendung antwortete nicht mehr. Ein spätere Analyse zeigte, sie hätte geantwortet, aber erst nach Tagen. Vielleicht kennt jemand von Ihnen diese Sorte von Problem. Diese gehören zu den schwersten in der Informatik und sind aller höchstwahrscheinlich nicht effizient lösbar. Die Begründung lies der Nikolaus nicht zu, er zahlte keinen Penny: Das Projekt ist vor die Wand gefahren. Vielleicht ist dies der Grund, war heutzutage auf der Welt noch alles so ungerecht verteilt ist?

37 Falle 7 Das bringt und zur letzten Falle 7 mit folgender Erkenntnis

38 Doch wie lässt sich das Problem bekämpfen?
Erkenntnis Selbst eine vollständige und widerspruchsfreie Spezifikationen garantiert keine gute Software! Doch wie lässt sich das Problem bekämpfen? Selbst eine vollständige und widerspruchsfreie Spezifikation garantiert keine gute Software. Doch wie lässt sich das Problem bekämpfen? Ich hatte Sie doch gebeten, sich etwas im Hinterkopf zu merken: Dieser Satz: Nenn mir doch mal ein Beispiel:

39 Specification by Example
Zwei Kinder, 6 Geschenke im Wert von 1, 2, 2, 4, 6, 9 Euro Lösung: = = Ungültig: = 11 < 13 = Zwei Kinder, 6 Geschenke im Wert von 1, 2, 2, 4, 5, 9 Euro Lösung: = 11 < 12 = Zwei Kinder, 10 Geschenke im Wert von 1, 1, 1, 1, 1, 1, 1, 1, 4, 4 Euro Lösung: = = Schlecht: = = 20 Kinder, 50 Geschenke im Wert von jeweils 1 Euro Lösung: 10 Kinder: 1 + 1, 10 Kinder: usw... Der RE hätte mit dem Nikolaus noch mehr konkrete Beispiele durchdiskutieren sollen. Dann wäre ihm spätestens bei einem solchen Fällen aufgefallen, dass es nicht damit getan ist, dass nur die Geschenksummen gleich sind. Und am besten hätte der RE dies auch gleich mit dem Entwickler besprochen: Dem wäre dann vielleicht bereits aufgefallen, dass es sich hierbei um ein schweres Problem handelt.

40 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 Hier noch mal die Idee, Das klassische Vorgehen läuft ein wenig wie Stille Post: 1) Der Kunde bespricht sein Produkt-Idee mit dem RE häufig anhand von Beispielen 2) Der RE abstrahiert dann und formuliert (Absicht: Formal oder Formel) eine Spezifikation 3) Der Entwickler entwickelt dann auf der Basis der Spec 4) Der Tester erstellt seine seine Testfälle anhand der Spec 5) Der Kunde nimmt die Software dann anhand seiner eigenen Akzeptanzkriterien ab. Warum sollte man die Bespiele, über die ganz am Anfang geredet wird, nicht bereits zu Testfällen machen? Diese können dann, wenn möglich sogar automatisiert ausgeführt werden und zu automatisierten Akzeptanztests werden. anhand der Spezifikation anhand von Akzeptanzkriterien

41 Idee des Acceptance Test Driven Development
werden zu Beispiele Tests reflektieren verifizieren Das ist die Idee des sog. ATDD: Beispiele reflektieren zunächst die Anforderungen. Dann werden sie zu Tests, die dann möglichst automatisiert die Anforderungen verifizieren Anforderungen

42 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. Wer schreibt nun Akzeptanztests? Die Idee beim ATDD ist, dass sich RE und Entwickler zusammensetzen und gemeinsam Akzeptanzkriterien besprechen und Tests ausarbeiten. Diese werden in natürlicher Sprache verfasst Vorrangiges Ziel ist ein gemeinsames Verständnis der Anforderungen Schön wäre ein einheitliches Format in Form einer Satzschablone mit dem Ziel, daraus Test-Code generieren zu können. Die ist die Idee des sog. Behavior Driven Developments Dies ist die Idee das sog. Behavior Driven Development (BDD)

43 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« Diese Satz-Schablone ist sehr einfach gehalten und besteht lediglich aus den Schlüsselwörtern "Angenommen, wenn, dann, und" oder auf English: Given, when, then Hier sehen wir eine User-Story zur Nikolaus-Aufgabe. Die Akzeptanzkriterien werden nun als sog. Scenarios in der sog,. Gherkin-Syntax ausgedrückt. Das geht dann so: Angenommen… Und… Falls… Dann…

44 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: = 5, Kind 2: = 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); Nun gibt es Tools, das bekannteste in wohl Cucumber, ich hab hier mal JBehave ausprobiert, die auf der Basis solcher Texteingabe Test ausführen können. Man gibt diese Text genau so in Prosa ein. Wichtig sind lediglich die Schlüsselwörter am Anfang. Nun lässt sich ein Java-Klasse generieren, die man natürlich noch ein wenig mit Leben füllen muss. Es muss das Rechenprogramm aufgerufen werden und dessen Ergebnisse mit den Sollvorgaben aus den Texteingaben vergleichen werden. s. auch [Jbehave] und [Cucumber]

45 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: = 5, Kind 2: = 5 Falls man diesen Test nun ausführt, so erhält man ein richtig schön lesbares Logfile. Damit man sieht, dass dies wirklich eine Testausführung und kein bloßes Ausgeben des Textes ist, habe ich hier mal den Sollwert von 5 auf 9 geändert und erhalte folgende Ausgabe. 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: = 5, Kind 2: = 9 (FAILED) (org.junit.ComparisonFailure: expected:<... 5, Kind 2: = [9]> but was:<... 5, Kind 2: = [5]>)

46 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 Noch mal zum Vergleich: hier das klassische Vorgehen. In diesem Fall finden Akzeptanztest erst spät statt und es gibt bei Implementations-Fehlern einen Rückweg zur Entwicklung, bei Fachlichen Fehlern zum RE und bei einem grundsätzlichen Infragestellen auch noch mal den Rückweg zum Kunden. Im Vergleich dazu das ATDD-Vorgehen: Hier setzen sich RE und Entwicklung zusammen und entwickeln zusammen Akzeptanztests. Dadurch werden fachliche Fehler und generelle Inkonsistenzen bereits zu diesem Zeitpunkt erkannt, d.h. die Feedbackschleife ist kürzer. Wenn alles optimal verläuft, entdeckt die QA dann nur noch Implementierungsfehler.

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

48 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? Auch diesen längeren Abschnitt möchte ich mit einigen Best Practices abschließen: 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.

49 Anforderungen aufnehmen Dokumentieren von Anforderungen
Der Effekt von Akzeptanztests Anforderungen vermessen und validieren Verwalten von Anforderungen Zusammenfassung Wo wir schon bei dem Überprüfen von Anforderungen sind, Kommen wir nun zu einer analytischen Maßnahme, dem Vermessen und Validieren von Anforderungen

50 Anforderungen vermessen und validieren
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… Warum sollte ich das tun? 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.

51 Kosten von RE-Fehlern bezogen auf Projektphasen
diese Grafik kennen wir bereits. Reparaturkosten aufgrund von Fehlern in den Anforderungen steigen überproportional je später man sie entdeckt.

52 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 Was sind nun Qualitätsmerkmale von Anforderungsspezifikationen? Ich habe mal einige aufgelistet. Wir sind ja hier bei den analytischen Maßnahmen. Also stellt sich die Frage: Wie kann ich denn beispielsweise das Qualitätsmerkmal Eindeutigkeit ganz konkret mit einer Zahl versehen?

53 Konkrete Qualitätsmetriken
Da haben sich die Sophisten die Mühe gemacht und für jedes dieser Qualitätsmerkmale eine Berechnung vorgeschlagen. Danach lässt sich in recht eindeutiger Weise jedes Dokument hin untersuchen. Dies sind Vorschläge, die man verwenden kann. Es ist genauso legitim, sich etwas eigenes auszudenken. Hauptsache man verwendet es über eine längere Zeit konstant. nach [RuppSoph]

54 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 Für die Überprüfung selbst gibt es nun ganz unterschiedlich schwergewichtige Verfahren. Da gibt es die Stellungnahme: Das ist das Vieraugenprinzip, d.h. eine weitere Person wird gebeten, das Dokument zu prüfen. Inspektion wurde 1976 von Michael Fagan bei IBM eingeführt und zählt seitdem zu einer der wichtigsten Review-Techniken. Die Inspektion ist ein strenger formalisierter Prozess mit vielen Beteiligten (Moderator, Prüfer, Termine, Checklisten, Abschlussbericht) Walkthrough Leichtgewichtiges Review. Der Autor trägt vor, die Gutachter hören aufmerksam zu und haken überall dort ein, wo sie Mängel entdecken. Automatisiert durch Tools Befindet sich in der Forschung

55 Prüfungsnachbereitung
Ergebnisse standardisiert dokumentieren Bei Unterschreitungen der Toleranzgrenze Ursachen bestimmen! Prozesse anpassen Evtl. nachschulen Um Aussage über Verbesserungen oder Verschlechterung machen zu können, müssen die Messergebnisse über eine länger Zeit aufgezeichnet werden. Sinnvoll ist es, sich bereits zu Beginn eine Toleranzgrenze zu überlegen und auch Maßnahmen, die bei einer Unterschreitung einzuleiten sind. Wichtig ist, die Ursachen zu bestimmen, ggf. die Prozesse anzupassen. oder auch über Schulungen nachzudenken.

56 Bezug zur Software-Qualität (exemplarisch)
Funktionalität Korrektheit Wartbarkeit Aktualität x Eindeutigkeit Widerspruchsfreiheit Identifizierbarkeit Vollständigkeit Änderbarkeit Prüfbarkeit Realisierbarkeit Verständlichkeit Nun dreht es sich ja heute eigentlich um Software-Qualität. Die Frage stellt sich: Wie hängen RE-Qualität und Software-Qualität zusammen? Das zeigt diese Abbildung. Auf der linken Seite stehen die anfangs gezeigten RE-Qualitätsmerkmale, oben habe ich exemplarisch drei Merkmale der Software-Qualität herausgesucht. Wo ein direkter Zusammenhang besteht hab ich mal ein Kreuzchen gemacht. Beispielsweise hat die Widerspruchsfreiheit natürlich einen Direkten Einfluss auf die Korrektheit. Oder die Verständlichkeit hat einen direkten Einfluss auf die Wartbarkeit.

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

58 Anforderungen aufnehmen Dokumentieren von Anforderungen
Der Effekt von Akzeptanztests Anforderungen vermessen und validieren Verwalten von Anforderungen Zusammenfassung Wir kommen nun zu dem Verwalten von Anforderungen.

59 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! Dies ist neben dem Beseitigen von unklaren Anforderungen die Hauptaufgabe vor allem des agilen RE, denn agile Projekte müssen definitionsgemäß mit einer größeren Anzahl von schnell-wechselnden Anforderungen umgehen können. Und da ist die Wahl eines richtigen Tools von großer Bedeutung, was direkte Auswirkung auf das Qualitätsmerkmal Wartung hat. Entscheidend für das Software-Qualitätsmerkmal Wartbarkeit

60 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 Wir erwarten von einem guten RE-Tool, dass es neben den Standard-Funktionen wie Anlegen, Ändern, Löschen eine gute Strukturierbarkeit und vor allem sehr gute Suchmöglichkeiten vorsieht. Versionsverwaltung und eine einfache Handhabung von Grafiktypen sollten vorhanden sein. Viel wichtiger als früher schätze ich den Traceability ein. Dazu komme ich gleich noch. Wünschenswert sind Konfigurierbarkeit von Eingabemasken und Workflows, eine Benutzerverwaltung und die Möglichkeit Texte automatisch zu analysieren.

61 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 … Leider sind immer noch Word und Excel die Haupt-Werkzeuge des REs, obwohl sie kaum eine einen der eben genannten Funktionen unterstützen. Der einzige Grund ist wohl, dass die Tools von jedem beherrscht werden. Mehr im Kommen sind Wikis und das Tool Jira von Atlassian: Grund: Einfaches Erlernen, Einfache Bedienung Offen für den Aufbau einer Werkzeugkette Beteiligt an dem Projekt Cloud9 Dann gibt es eine recht große Anzahl von speziellen RE-Tools, von der ich hier einen Ausschnitt zeige. Meine Erfahrung ist, dass sie wenig eingesetzt werden, eine Ausnahme stellt wohl das Tool DOORS dar, was man recht häufig im Automotive-Bereich findet. Grund: Jeder von uns weiß die Vorteile eines Navigators zu schätzen. Aber wenn ich einen meiner Mutter schenke: Sie würde in nicht benutzen! Bei den Tools lag der Fokus nicht so sehr auf der Useablity. [VolereTools] enthält eines weitaus größere Übersicht

62 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? … Traceability oder Verfolgbarkeit meint die Möglichkeit innerhalb eines RE-Tools oder sogar über seine Grenzen hinaus zu einem Aspekt der Software alle Informationen finden zu können. Wenn das gut funktioniert, spart das bei Wartungsprojekten unheimlich Zeit. Angenommen der Kunde kommt mit einem Ticket: Im Risiko-Report vom 31.3 stimmt das Ausfalldatum nicht. Wie findet der Entwickler die notwendigen Informationen? 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?

63 Ideale Welt RE-Tool Modellierung RE-Tool RE-Tool Source "Ausfalldatum"
Lösung RE-Tool Modellierung Fachklassen "Ausfalldatum" RE-Tool Suchergebnis Anforderung RE-Tool Source Verarbeitung In einer idealen Welt sähe das so aus: Das Ausfalldatum kommt in folgenden Teilen vor: Optimal ist es, wenn man "Ausfalldatum" in das RE-Tool eintippt und man als Suchergebnis eine Anforderung und eine Lösung erhält. Schön wäre auch, wenn diese miteinander verlinkt wären. Noch schöne wäre es, wenn er eine Referenz zu einem anderen Tool gäbe, beispielsweise zu einem Modellierungstool und eine Referenz (Link) in den SourceCode.

64 Source-Code-Analysen können das zig-fache an Zeit kosten!
Die Realität Source DB-Tool Word X Die Realität aber meist anders aus. Man könnte in einer mit Word verfassten Anforderung suchen, tut es aber nicht, denn bis man das richtige Dokument mit der richtigen Version findet und dort in dem Dokument die richtigen Stellen findet. Und hilft einem die Info dann überhaupt? Also beginnt der Entwickler meist sofort im Source-Code zu suchen, denn das ist ja sein Haupttool, in der Hoffnung dort die Stellen zu finden. GGf. zieht man ein DB-Tool hinzu. Solche Source-Code-Analysen können des zigfache an Zeit kosten! Wir haben jetzt einen Fall: Andy, der mich ablösen soll. Der Source-Code-Analysen können das zig-fache an Zeit kosten!

65 Vision: Traceability innerhalb der Werkzeugkette
Issue Tracking Projekt-management Collaboration Anforderungs-management IDE Monitoring Meine Vision besteht darin, eine Traceability unter des verschiedensten Tools einer Werkzeugkette zu ermöglichen. Da gibt's inzwischen gute Ansätze, aber das geht jetzt schon ein wenig über das RE hinaus. Modellierung Build- Management Delivery BP-Management Configuration- Management Persistenz

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

67 Anforderungen aufnehmen Dokumentieren von Anforderungen
Der Effekt von Akzeptanztests Anforderungen vermessen und validieren Verwalten von Anforderungen Zusammenfassung Kommen wir zum Ende

68 Warum ist RE wirtschaftlich?

69 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 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 Anforderung -> Software-Qualität Vielen Dank fürs Zuhören

70 [RuppSoph] Chris Rupp, die SOPHISTen; Requirements-Engineering und –Management, 5. Auflage, Hanser, 2009, ISBN: [VolereTools] [Cucumber] [Jbehave] [bdw]

71 Klaus Pohl, Chris Rupp; Basiswissen Requirements Engineering; 2
Klaus Pohl, Chris Rupp; Basiswissen Requirements Engineering; 2. Auflage, Dpunkt Verlag, 2010, ISBN: S. Robertson, J. Robertson; Mastering the Requirements Process; Addison Wesley, 1999, ISBN: U. Vigenschow, B.Schneider, I. Meyrose; Soft Skills für Softwareent-wickler; 2. Auflage, Dpunkt Verlag, 2010, ISBN: Rainer Gerlich; 111 Thesen zur erfolgreichen Softwareentwicklung; 1. Auflage, Springer, 2005, ISBN:

72 Mr. Malcolm Tredinnick, Behaviour Driven Development, http://www
Gojko Adzic; Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing; Neuri Limited, 2009, ISBN: Gojko Adzic; Specification by Example: How Successful Teams Deliver the Right Software; Manning, Juni 2011, ISBN:

73 Bildernachweise Folie 9: Folie 13: Folie 19: Folie 29: 800px-Lage-_und_Verhältnisbestimmung_Zahn.jpg Folie 32: Folie 33: … Clean Code

74 Bildernachweise Folie 33: Folie 55: Folie 64: Sämtliche hier nicht aufgeführte Bilder bzw. Grafiken wurden vom Autor selbst erstellt. Clean Code

75 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

76

77