Neues von der REFSQ Requirements Engineering: Foundation for Software Quality
Essen, 27. Februar bis 2. März
Drei Tage Konferenz mit parallelen Sitzungen fasst man nicht mal schnell in fünf Zeilen zusammen. Ich habe darum das herausgesucht, was auch aus praktischer Sicht handfest nützlich ist. Auf einer wissenschaftlichen Tagung werden ja auch vorläufige Ergebnisse, Forschungsvorschauen, Ideen und Meinungsbeiträge veröffentlicht.
Grundsätzlich scheint der Trend im Requirements Engineering in Richtung Automatisierung zu gehen. Das widerspricht nicht unserer Vision eines kreativen Requirements Engineering, denn es gibt genug unkreative Tätigkeiten in diesem Bereich. Jede langweilige, routinemäßige Tätigkeit ruft ja geradezu nach Automatisierung, um den Kopf für neue Ideen frei zu halten.

Ein guter Teil der Automatisierung betrifft die Identifikation und Analyse von natürlichsprachlichen Anforderungen. Nachdem diese eigentlich chaotische Art der Anforderungsspezifikation in der Praxis immer noch vorherrscht, machen wir das Beste daraus.

• Prof. Lionel C. Briand gab in seinem Keynote-Vortrag "Analyzing Natural-Language Requirements: The Not-Too-Sexy and Yet Curiously Difficult Research that Industry Needs" eine Übersicht über die automatisierte Bearbeitung von Text allgemein und Anforderungen im Speziellen. Ziel der Textanalyse ist beispielsweise die Übersetzung, Qualitätsprüfung, aber auch die Impact Analyse, d.h. herauszufinden, welche anderen Textstellen noch zu ändern sind, wenn qeine Anforderung sich ändert. Nähere Informationen zum Tool RETA (für Vorlagen-Compliance-Prüfung) finden Sie hier. Das Werkzeug Narcia führt eine Change Impact Analyse durch.
• Martin Wilmink, Christoph Bockisch: On the Ability of Lightweight Checks to Detect Ambiguity in Requirements Documentation. pp. 327-343. Natürlichsprachliche Anforderungen leiden unter anderem unter dem Nachteil, dass sie uneindeutiger sind als Modelle. Diese Arbeit hat ein Werkzeug namens tactile check entwickelt, das Mehrdeutigkeiten in Anforderungen automatisch findet. Nähere Informationen zum Werkzeug bei Github.
• Garm Lucassen, Fabiano Dalpiaz, Jan Martijn E.M. van der Werf, and Sjaak Brinkkemper:
  Improving User Story Practice with the Grimm Method: A Multiple Case Study in the Software Industry. pp. 235-252. Hier wird die Qualitätssicherung von User Stories automatisiert mit Hilfe des computerlinguistischen Werkzeugs Automatic Quality User Story Artisan (AQUSA). Die Kombination von AQUSA mit dem Quality User Story (QUS) Framework nennt sich die Grimmsche Methode. Ausprobiert wurde die Methode von 30 Praktikern in drei Firmen für zwei Monate. Die Qualität der User Stories verbesserte sich tatsächlich messbar, die Teilnehmer fanden die Unterschiede jedoch weniger wichtig.
• Paul Hübner, Barbara Paech: Using Interaction Data for Continuous Creation of Trace Links Between Source Code and Requirements in Issue Tracking Systems. pp. 291-307. Diese Arbeit kümmert sich um das Stiefkind Traceability. Da diese üblicherweise händisch nur nachlässig gepflegt werden, verspricht die automatische Identifikation von Traceability-Verknüpfungen praktische Hilfe. In einer Fallstudie wurden solche Links automatisch im Issue Tracker System (ITS) gefunden und angelegt.
• Carles Farré, Xavier Franch, and Tudor Ionescu: State of the Practice on Software Release Planning. Dieser Beitrag aus dem PrioRE-Workshop untersuchte die Fähigkeiten von Release-Planungs-Werkzeugen und verfolgte dabei die Idee zu prüfen, wie weit Algorithmen aus der künstlichen Intelligenz dort bereits eingesetzt werden. Ihre frühere Literaturstudie hatte gezeigt, dass von den vielen entsprechenden Forschungsansätzen nur einer den Sprung zum kommerziellen Werkzeug geschafft hatte. Nun untersuchten sie umgekehrt, was sich in real existierenden Werkzeugen befindet. Den Artikel finden Sie online hier.
• Norbert Seyff, Melanie Stade, Farnaz Fotrousi, Martin Glinz, Emitza Guzman, Martina Kolpondinos-Huber, Denisse Munante Arzapalo, Marc Oriol, Ronnie Schaniel: End-user Driven Feedback Prioritization. Dieser Beitrag aus dem PrioRE-Workshop beschäftigt sich, wie man das Feedback von Endnutzern einer Software automatisiert auswerten und bewerten kann, ohne dass ein Mitarbeiter die Textfülle lesen und sortieren muss. Die Autoren können noch keine fertige Lösung präsentieren, zeigen jedoch erste Ideen für Lösungswege auf. Den Artikel finden Sie online hier.

Weitere handfeste Ergebnisse lieferten folgende empirischen Studien:

• Irum Inayat, Sabrina Marczak, Siti Salwah Salim, and Daniela Damian: Patterns of Collaboration Driven by Requirements in Agile Software Development Teams -
  Findings from a Multiple Case Study. pp. 131-147. Hier wurden in mehreren Fallstudien die Kommunikationsmuster innerhalb verteilten agilen Teams untersucht. Das erstaunlichste Ergebnis besteht darin, dass die Entfernung keine Rolle zu spielen scheint. Ältere Studien legen eher nahe, dass jede Treppenstufe schon die Kommunikationshäufigkeit und -qualität mindert. Allerdings kann ich mir gut vorstellen, dass hier zwei Faktoren dazu führen, dass es in modernen agilen Teams besser läuft: Erstens wird in agilen Teams die Kommunikation sehr stark betont und geregelt und zweitens ist es für uns heute völlig normal, mit Menschen zusammen zu arbeiten - oder auch privat befreundet zu sein - die sich weit entfernt befinden.
• Katsiaryna Labunets, Fabio Massacci, and Federica Paci: On the Equivalence Between
  Graphical and Tabular Representations for Security Risk Assessment . pp. 191-208. In zwei Experimenten wurden zwei alternative Notationen für Sicherheitsrisiken miteinander
  verglichen: graphische Notationen und Tabellen. Beide erwiesen sich als gleichwertig
  bezüglich ihrer Effektivität.

CreaRE 2017: Sixth International Workshop on Creativity in Requirements Engineering

Das wichtigste Event im Februar war für mich die REFSQ-Tagung, bei der ich seit 2005 Teilnehmerin und meist auch Mitorganisatorin bin. Dieses Jahr bestand mein Beitrag darin, zum sechsten Mal den CreaRE-Workshop zu organisieren. Er fand am 27. Februar in Essen statt. Das Programm bestand aus drei Vorträgen und einer interaktiven Sitzung.

• Luisa Mich, Victoria Sakhnini and Daniel Berry: Downsizing EPMcreate to Lighter Creativity Techniques for Requirements Elicitation. EPMCreate ist eine kreative Methode, um Requirements zu erheben durch den definierten Wechsel der Perspektive. Die Methode umfasst in ihrer ursprünglichen Form 16 Schritte, was sich als recht aufwändig herausgestellt hat. Darum verfolgte dieser Vortrag die Frage, wie man aus den 16 Schritten einschrittige, zweischrittige, dreischrittige usw. Methoden entwickeln kann und welche davon schon existierenden Kreativitätstechniken entsprechen. Am Ende sollen alle Perspektiven abgedeckt sein.
• Eduard C. Groen, Matthias Koch and Andreas Maier: Vicus – A Persona for Towns:
  Die Autoren beschäftigen sich damit, Anforderungen für den Bereich Smart Towns zu erheben. Hier sind die Bedingungen etwas anders als sonst im Requirements Engineering. Nicht einzelne Stakeholder oder Gruppen sollen betrachtet werden, sondern ganze Städte oder Dörfer als Gemeinschaft. Darum verwenden die Autoren hier Personas, um eine ganze Stadt zu charakterisieren. Dabei verwenden sie eine entsprechende Vorlage.
• Nils Kubischok: Imagining the future: A social science approach to the importance of visions in the software development process. Die Sozialwissenschaften wissen, wie erwartungsformend und handlungsweisend Visionen auf Menschen wirken. Im Requirements Engineering wird dies bisher nur erahnt. Dieser State of the Art Artikel zeigt dies in einer Übersicht und begründet die Bedeutung von Visionen im Requirements Engineering.
• Kristian Beckers, Veronika Fries, Eduard C. Groen and Sebastian Pape: Creativity Techniques for Social Engineering Threat Elicitation: A Controlled Experiment (interactive session): Für dieses Experiment wurden wir in drei Gruppen aufgeteilt. Alle Gruppen verfolgten das Ziel, Social Engineering Bedrohungen zu finden, die einer Konferenz gefährlich werden können. Die einen spielten ein Kartenspiel, ein Serious Game, die anderen sammelten per Brainstorming jeweils Listen von Opfern (victims), Werten (assets), Angriffskanälen (channels), psychologischen Prinzipien (psychological principles), Angriffen (attacks) und Angreifern (attacker) und kombinierten mit Hilfe der Technik Morphological Forced Connections diese miteinander zu konkreten Angriffsszenarien.

Ich war in der zweiten Gruppe. Da wir für jede Kategorie jeweils ungefähr 10 Ergebnisse fanden, überschlug ich schnell, dass wir im Prinzip bis zu einer Million Szenarien bilden können. Das fühlte sich etwas frustrierend an. Womit beginnen? Grundsätzlich glaube ich aber, dass wir so ziemlich alles gefunden haben, was man sich nur denken kann.
Die Gruppe "Kartenspiel" berichtete von Spielspaß und dem Vergnügen, hinterhältig zu sein.
Sie fanden die Karten hilfreich, gerade für Nicht-Experten, die sich über Social Engineering
zuvor noch keine Gedanken gemacht haben, um in die Thematik sehr anschaulich hinein
zu kommen.
Die Ergebnisse der beiden Gruppen werden im Nachgang wissenschaftlich miteinander verglichen. Ich bin gespannt, was dabei herauskommen wird!

Die Vortragsfolien können Sie von der Workshop-Webseite herunterladen unter "Workshop Program" und die zugehörigen Proceedings sind hier online.
Hier finden Sie auch die Proceedings der anderen REFSQ-Workshops.

Neues von den Software Quality Days SQD
Die SQD fand am 17. bis 20. Januar in Wien statt. Auf dieser eher praxisorientierten Konferenz werden Best Practices und Erfahrungen ausgetauscht. Ich selbst hielt am 20. Januar einen Workshop über Ethische Entscheidungen im Software Engineering ab.

Von den Vorträgen gefielen mir diese am besten, weil sie wirklich Neues und Nützliches brachten:

• die beiden Vorträge von den Herren Jürgen und Pagano über Test Gap Analyse:
  "Haben wir das Richtige getestet? Erfahrungen mit Test-Gap-Analyse im Hotfix-Test, Iterationstest und Releasetest in der Praxis" und "Oh nein, morgen ist Release! - Test-Gap-Analyse live am Beispiel".
  Es handelt sich dabei um die Visualisierung von zwei unterschiedlichen Aspekten derselben Software als Tree Map: Die Information, welche Codestellen geändert wurden, und welche bei Tests ausgeführt wurden. Besonders kritisch sind diejenigen, die zwar geändert, aber nicht getestet wurden. So offenbart sich Nachholbedarf. Natürlich macht man diese Auswertungen nicht von Hand, sondern mit dem Werkzeug TeamScale, das sich momentan noch in der Pilotphase befindet und kostenlos erhältlich ist. Noch.
  Die Folien des ersten Vortrags mit Screenshots stellen die Autoren hier zur Verfügung.
• Und mal wieder ein Sneedscher Vortrag über die COBOL-Java-Migration:
  Harry M. Sneed, Chris Verhoef: Validating converted Java Code via Symbolic Execution.
  Wie findet man eigentlich heraus, dass der Java-Code exakt dasselbe tut wie der COBOL-Code? Man hat ihn ja idealerweise bei der Migration restrukturiert! In meiner Vorlesung lehre ich eigentlich, dass es praktisch unmöglich ist, zwei Computerprogramme exakt miteinander zu vergleichen. Behaupten die Theoretischen Informatiker. Sneed ist es trotzdem gelungen: Er vergleicht die Kontroll- und Datenflüsse beider Programme durch symbolic execution.

Am 24.-26.04. 2017 findet das Seminar "Requirements Engineering nach IREB" an der Technischen Akademie Esslingen statt. Dieser Kurs bereitet auf die Zertifizierungsprüfung zum CPRE Foundation Level vor.

Gerade lese ich die Beschreibung des Gutachter-Sachgebiets "Informationstechnologie" unserer Stuttgarter IHK. Hier steht auf Seite 3 oben: "Trend-Begriffe wie Big Data, Cloud-Computing, Webshop sind bewusst nicht als Zusatzgebiete vorgesehen, da nicht zu erwarten ist, dass diese von Dauer sind." Als ich das las, hätte ich mich beinahe verschluckt, weil gerade diese drei Technologien ganz sicher von Dauer sein werden. Sie sind der Dose der Pandora entkommen und werden sich hartnäckig halten, weil ihr Vorteil und Nutzen offensichtlich groß sind. Dieses Merkblatt ist von 2015, aber ich vermute, dieser Satz ist schon älter und wurde bei späterer Überarbeitung einfach überlesen. Hoffe ich.

Hier finden Sie einen Artikel über die Vorteile von real life Trainings im Vergleich zu E-Learning. Obwohl ich wirklich ein Fan von E-Learning, Webinaren und MOOCs bin, besuche ich selbst immer noch Schulungen im echten Leben, an fernen Orten, mit Menschen statt Avataren. Reisekosten und Reisezeiten investiere ich selbst, um mich zu vernetzen, einem Experten mal eine konkrete Frage stellen zu können oder etwas praktisch auszuprobieren und sofort Feedback zu erhalten. So gesehen muss ich nicht fürchten, als Trainerin irgendwann nicht mehr gebraucht zu werden, weil die Lernenden ihre Fragen von Bots beantwortet bekommen, Kurse bei Youtube kostenlos ansehen und Wissen online anhand von Computerspielen erproben.
E-Learning-Kurse finde ich v.a. dort überlegen, wo jemand sich ganz allein in Ruhe Gedanken machen will oder soll, oder Wissen für eine Multiple Choice Prüfung auswändig lernen soll. Man kann beim E-Learning gut sein Tempo selbst wählen.
Auf jeden Fall jedoch müssen wir als Trainer unsere Rolle überdenken in einer Welt, wo Faktenwissen an sich und Youtube-Vorträge kostenlos erhältlich sind. Aber dieses Überdenken haben die Kursteilnehmer bereits erledigt. Reiner Vortragsstil ist nicht mehr erwünscht. Die Teilnehmer kommen zum Diskutieren, Austauschen, Ausprobieren in Schulungen.
Andrea Herrmann

Inzwischen können Computer auch Sprache von den Lippen ablesen. Über die Konsequenzen möchte ich nicht so genau nachdenken. Konnte man sich bisher vor Belauschen noch durch Nebengeräusche schützen, genügt jetzt auch eine tonlose Filmaufnahme eines Gesprächs, um weitere Rückzugsorte unserer Privatsphäre zu zerstören. Ich warte nur noch auf die Künstliche Intelligenz, die unsere Gedanken ausliest. (Es wird ja schon seit Jahrzehnten daran gearbeitet, damit Querschnittsgelähmte Computer durch ihre Gehirnströme steuern können.) Sobald die Gedankenübertragung vom Gehirn auf den Computer vollständig funktioniert, sind selbst die Gedanken nicht mehr frei. Über die umgekehrte Richtung (Gedankenübertragung von Computer auf Gehirn) möchte ich ebenfalls nicht näher nachdenken. Die Realität hat die Science Fiction schon längst überholt! Ich kann mir keine so richtig schlimmen Zukunftsszenarien ausdenken, für die uns völlig die technische Unterstützung fehlt. Ganz abgeschlossen ist die Entwicklung noch nicht, aber inzwischen mangelt es nur noch an Zusatzfunktionen oder der Qualität bereits vorhandener Möglichkeiten.
Andrea Herrmann

Mein Vortrag auf der enterJS ist nun online unter dieser Adresse. Es geht darin um die Verheiratung von Requirements Engineering und agiler Entwicklung, um die Grauzone zwischen klassischem, schwergewichtigem Requirements Engineering und agilem, leichtgewichtigem Requirements Engineering.

Die klassischen Requirements Engineering Methoden und agile Entwicklung scheinen sich gegenseitig auszuschließen. In der agilen Entwicklung braucht man kein Lastenheft, weil Dokumentation durch Kommunikation ersetzt wird.

Tatsächlich sind aber die leichtgewichtigen Anforderungen - beispielsweise in Form von User Stories - in der agilen Entwicklung von zentraler Bedeutung, weil sie nicht nur die Grundlage für Entwicklung und Test darstellen, sondern auch für das agile Projektmanagement. Während das agile, leichtgewichtige Requirements Engineering den Vorteil mit sich bringt, schnell mit der Programmierung beginnen zu können und dann die Software als Diskussionsgrundlage verwenden zu können und außerdem möglichst flexibel zu bleiben, besteht doch der Nachteil darin, dass ein Gesamtkonzept fehlt, die Struktur der Software allmählich immer chaotischer wird, und man vor lauter User Stories den roten Faden nicht mehr sieht. Als Lösung wurden Epics und Storymaps eingeführt. Dadurch nähert sich das agile Requirements Engineering dem klassischen wieder ein wenig an.

Dieser Vortrag stellt einige Möglichkeiten der Kombination von klassischem Requirements Engineering und agiler Entwicklung dar. So kann man beispielsweise - wie im Feature-Driven Development - zunächst eine Beschreibung und Konzeption für das Gesamtsystem erstellen und dann agil oder nebenläufig die Features einzeln entwickeln.
Oder die klassischen Requirements Engineering Methoden werden nach einer initialen agilen Prototypphase eingesetzt, um nun eine saubere Anforderungsanayse durchzuführen und ggf. das System refaktorieren, nicht nur technisch, sondern auch dessen Benutzeroberfläche.
Andrea Herrmann

Es gibt im Internet eine Webseite mit einer Hitliste für schlechte Software-Werkzeuge. Auch einige bekannte Software Engineering Werkzeuge haben es unter die Top 30 geschafft. Leider fehlen qualifizierte Begründungen. Aus wissenschaftlicher Sicht ist die Liste auch nicht wirklich valide. Man müsste eher messen, welcher Anteil derer, die ein Tool kennen, es gut oder schlecht finden. So landen natürlich die verbreitetsten und die Marktführer automatisch weiter oben (also schlechter) als unbekannte Exoten. Aber interessant ist es doch. Ich habe gerade auch zwei Stimmen abgegeben für zwei Tools, die ich aus Erfahrung meide.

Gerade erschien mein Gastbeitrag "Zertifizierung - lohnt sich das?" im Blog Systems Engineering Trends. In diesem Artikel geht es um den Sinn und Unsinn von Zertifizierungen. Insgesamt sind sie besser als ihr Ruf, wenn man sie richtig nutzt. Man sollte ja bekanntlich fürs Leben lernen und nicht nur für die Prüfung!

In Zusammenarbeit mit der SIGS DATACOM veranstalte ich am 13.-14.03. in Köln den Kurs "Maßgeschneidertes Requirements Engineering - Nicht zu viel und nicht zu wenig Spezifikation". In diesem Seminar arbeiten wir in einer Kleingruppe an Ihrer persönlichen Prozessverbesserung für Ihr Requirements Engineering. Dazu analysieren wir die Stakeholder Ihres Requirements Engineerings und deren Bedürfnisse, und erarbeiten Lösungen.