Verstandene Anforderungen für jedermann!

Expedition REConf 2019

By am Mrz 25, 2019 in Video, Vorträge, Wissen | 0 comments

Lesezeit 7:46 Minuten

Prost!

3 Tage RE-Conf2019 in München,
3 Tage volle Ladung Input.
Zugehört, Notizen gemacht und einen eigenen Vortrag über das „BigPicture 360°“ gehalten.
Viel sitzen, viel Nackenverspannung – versüßt mit Vorträgen, die Wert stiften.


Zusammenfassung Vortrag:

Requirements Engineering 4.0

Von: Peter Nicke

Metasprache entwickeln – damit alle das Gleiche verstehen können:

Das kennst Du – jeder Autor einer Dokumentation spezifiziert so, wie es ihm in den Kram passt.

Tool gestützte Metasprache etablieren:

Da ist es genial, wenn ich ein Tool anbiete, das das Problem löst. Der Autor muss sich nicht verbiegen, sondern der Autor wird bei der Formulierung der Spezifikation unterstützt. Jeder Autor kann seinen synonymen Begriff nennen wie er will – dass Tool schlägt Ersetzungen vor, die standardisiert und vor allem – verständlich sind. Es wird so eine Metasprache erstellt, die eindeutig, abgestimmt und im Team akzeptiert ist.

Beispiel für die Metasprache:

Quelle: Vortrag Requirements Engineering 4.0
Die Abbildung zeigt eine Anforderungen und den zugehörigen Testfall, die in der Metasprache beschrieben sind.


Zusammenfassung Vortrag:

Business Visualisierung – eine kreative Reise in die Welt von Role Model Canvas

Von: Daniel Reinold & Christian Botta

Die Kraft der Bilder – Bilder sagen mehr als 1000 Worte! Meine Rede…

Daniel und Christian haben abwechselnd moderiert und gezeichnet.
Sozusagen „quod erat demonstrandum“ wurde die Wirkmacht von Bildern gezeigt, (grafische Anker / ein gemeinsames Mindset) geschaffen, die man sich besser merken kann. Die Idee ist, dass man mit Bildern sicherer kommunizieren kann.

Bildquelle: Präsentation Vortrag

Die Sinuskurven – geile Sache!

Mit der Sinuskurve kann man Höhen und Tiefen zeichnen. Hab das bereits in einem Training eingesetzt – hat gut funktioniert. Unten siehst Du „Anna“ über „Paul“ – da kann man im Training zum Beispiel sagen, dass es Anna besser geht als Paul.

Bildquelle: Präsentation Vortrag

Die richtige Metapher erzählen.

Es geht darum, die richtige Bilder-Geschichte/Metapher für die richtige Situation zu erzählen, sodass die Metaphern für die Menschen stimmig sind.

Weiter habe ich mitgenommen, dass Canvas nicht nur als Business-Modell-Canvas funktionieren. Ich bin gespannt.


Zusammenfassung Vortrag:

Cyber Security – Anforderungen – Angriff ist die beste Verteidigung

von Sabine Wildgruber und Dagmar Moser

Ich weiß immer noch nicht, ob meine Apple Watch sicher ist – und das ist schade, denn der Vortrag wurde am Beispiel einer Smartwatch dargestellt (und die war definitiv nicht von Apple ;o). In dem Sicherheits-Beispiel ging es darum, dass eine Smartwatch für Kinder zurückgerufen werden musste. Hackern war es möglich, auf die Uhr zuzugreifen und so den Standort der Kinder rauszufinden.

„Evil“- & Security-Stories

Ein Requirements Engineer sollte sich die Anwenderfälle von Hackern genau anschauen und dann gezielt funktionale Anforderungen entwickeln, die die Hacker-Anwenderfälle unterbinden (Security-Stories).

Normen

Sabine meinte, der „BSI IT-Grundschutz“ sei verständlich und zielführend – na denn, ich bin gespannt.
Weitere Normen:
– ISO 2700X
– IEC 62443
– Common Criteria (ISO/IEC 15408)

6 wichtige Fragen und das Bedrohungsszenario einzuschätzen.

Wie könnte ein Angreifer das System hacken?
1. Wer nützt die Anwendung wofür?
2. Welche weitern Akteure gibt es?
3. Wie vertrauenswürdig sind die Akteure meiner Anwendung?
4. Wer sind meine potentiellen Angreifer?
5. Was sind die Werte meiner Anwendung, die ich schützen will?
6. Wie sieht meine technische Architektur aus?

Bedrohung bewerten – 5 DREAD Faktoren

  • Damage: Welchen Schaden könnte ein erfolgreicher Angriff anrichten?
  • Reproducibility: Wie leicht ist es den Angriff “nachzubauen“?
  • Exploitability: Was benötigt man um den Angriff durchführen zu können?
  • Affected Users: Wieviele Benutzer sind betroffen?
  • Discoverability: Wie leicht wird die für den Angriff erforderliche Schwachstelle gefunden?

Zusammenfassung Vortrag:

Beyond RE ist Digital Design

Von: Dr. Kim Lauenroth, adesso AG / IREB e.V. / Bitkom AK Digital Design

Requirements Engineering goes „Digital Design“

Hallo Herr Bau-Architekt

Kim ist der Meinung, dass der digitale-Designer das Äquivalent für Bauarchitekten ist.
Bei Bauvorhaben denkt man ganz selbstverständlich an Architekten, die für die Gestaltung von Gebäuden verantwortlich sind und gezielt dafür ausgebildet werden. Aber an wen sollte man denken, wenn es um die Gestaltung von Digitalisierungsvorhaben geht? Hier fällt die Antwort nicht so leicht und eindeutig aus – der Digital Designer soll diese Lücke schließen. Quelle: DigitalDesing-Manifest

gutes Digitales Design:

  • ist nützlich und gebrauchbar.
  • ist elegant und ästhetisch.
  • ist evolutionär.
  • ist explorativ.
  • nimmt den ganzen Menschen in den Fokus.
  • antizipiert die Auswirkungen seiner Ergebnisse.
  • achtet den Datenschutz und die Datensicherheit.
  • ist nachhaltig und schafft Nachhaltigkeit.
  • würdigt Analoges und Digitales in gleicher Weise.
  • nutzt Digitales, wo es erforderlich ist.

Digital als Material – Analogie zum Bauhaus…

Das fand ich ziemlich spannend.
Hier wurde eine Analogie zum Bauhaus gebildet.
Das Bauhaus verfolgt eine ganzheitliche Lehre. Man lernt dort
nicht nur „Architektur“ sondern auch was die Architektur ausmacht – also zum Beispiel das Material, das verbaut wird und wie der Prozess aussieht das Material herzustellen.
Übertragen auf das digitale-Design bedeutet das, dass nicht nur Konzepte erstellt werden (typische RE-Aufgabe), sondern ganzheitlich gedacht werden soll. So sollten Gestaltungsprozesse, Umsetzungsprozesse etc. insgesamt gestaltet werden. Also nicht nur ein Haus bauen, sondern darüber nachdenken, was Beton oder Holz mit den Bewohnern macht und wie die Beschaffenheit ist…

Digitization, Digitalization, Digital Transformation

Diese 3 Begriffe stehen für die Veränderung der eigentlichen Digitalisierung.

  1. Früher war Digitalisierung physische Nachrichten als Daten abzubilden und zum Beispiel im BTX darzustellen (Digitization=gestalten von Material).
  2. Dann ist man dazu übergegangen Prozesse zu digitalisieren, da ist dann beispielsweise Google-News bei rausgekommen (Digitalization=gestalten von Prozessen).
  3. Und die derzeit aktuelle Stufe ist, dass Geschäftsmodelle insgesamt digitalisiert werden. Als Beispiel Twitter oder Facebook. Hier werden die News nicht mehr von Zeitungen gemacht, sondern von den Nutzern des Systems (Digital Transformation=Gestalten von Geschäftsmodellen).

Zertifikat (IREB):

Für den Digital Designer möchte das IREB ein Zertifizierungssystem anbieten. Es weitert das klassische Aufgabengebiet des Requirements Engineers.


Zusammenfassung Vortrag:

‘Agilität vs. Modellierung’ oder ‘Agilität & Modellierung’?

Von: Michel Goumet -MID GmbH

Durch die Agilität fällt die Dokumentation flach – dass gefällt nicht nur mir nicht, dass kann niemanden gefallen. Denn wer will den Systeme, die keiner mehr versteht? Anscheinend viele…
Michaels These: Mit zunehmender Komplexität ist modellbasierte Dokumentation besser als Textwüsten.

Wo wird in der Agilität modelliert

  • Items für das Produkt-Backlog
  • im Sprint
  • Verfeinerung der Anforderungen
  • Anforderungen schreiben
  • beim Kunden, wenn das Produktinkrement vorgestellt wird.

Bildquelle: Präsentation Vortrag

Was wird modelliert?

Alles:

  • wenn es zum Verständnis des Gesamtbildes notwendig ist
  • wenn es zum Verständnis besser beiträgt als andere Darstellungsformen
  • wenn es zum vereinbarten Lieferumfang gehört (z.B. grafische Darstellung aller Prozesse)

Nichts:

  • wenn das zu erstellende Produkt eine geringe Komplexität aufweist

Whiteboard vs. Tool

Klassen, Abläufe lassen sich auch wunderbar für Witeboardzeichnungen nutzen. Michaels Erfahrung ist, dass auch Menschen ohne UML-Kenntnisse diese verstehen.

Welche UML-Form ist für was geeignet?

Anforderungen:

  • Systemkontext
  • Fachklassen/Fachattribute
  • Anwenderfälle/Userstories
  • Abläufe

Architektur

  • Architekturstories
  • Komponentendarstellung
  • Schnittstellen

Anwendungsdesign

  • Klassen und Operationen
  • Sequenzflüsse

Fazit

  • Diagramme helfen dem Team, sich auf einzelne Aspekte zu fokussieren Diagramme fördern die Kommunikation
  • Modellextrakte können den Aufwand für das Review reduzieren
  • Eine einfache, intuitive Herangehensweise fördert die Akzeptanz

Zusammenfassung Vortrag:

Requirements Engineering for Machine Learning

Von: Prof. Dr. Andreas Vogelsang
Technische Universität Berlin

Traditionelles Programmieren vs. maschinelles Lernen.

  • Im traditionellen Programmieren werden Algorithmen geschrieben, die Problem lösen.
  • Beim maschinellen Lernen wird ein mathematisches Modell trainiert, Probleme zu lösen.
  • Das maschinelle Lernen unterteilt sich in 2 Phasen:
  • Training
  • Vorhersage

Es gibt 3 Arten von maschinellem Lernen

  • überwachtes Lernen
  • nicht überwachtes Lernen
  • Stärkung des Lernprozesses

Entwicklung verändert sich

traditionelles Programmieren maschinelles Lernen
Wissen ist das Programm Das Wissen ist in den Daten
Programmqualität ist wichtig Datenqualität ist wichtig
Fokussierung auf Korrektheit Fokus auf Unsicherheit
Input+Programm=Output Input+Output=Programm

Das Requirements Engineering verändert sich

Andreas ist der Meinung, dass maschinelles Lernen spezielle Anforderungen an das Requirements Engineering stellt.

Für das Requirements Engineering ist der Algorithmus des maschinellen Lernens eine Blackbox.
Der Requirements Engineer kümmert sich ausschließlich um die Daten, die Grundlage des maschinellen Lernens sind und um die Qualität des Outputs der Vorhersage.
Zudem ändern sich die funktionalen Anforderungen.

Abb.:Auswirkungen auf die 4 Haupttätigen des Requirements Engineering
Quelle: Präsentation zum Vortrag.

Diskriminierung einprogrammiert?

Entscheidend ist die Qualität der Daten, mit denen der Algorithmus trainiert – und hier kann vermutlich viel Unsinn anstellen. Aktuell sind häufige Problem beim maschinellen lernen, dass einzelne Menschen diskriminiert werden, weil der Algorithmus diese aussortiert. Ein Beispiel der Arbeitsagentur kannst Du Dir hier anhören. Der Podcast trägt den Titel „Wenn Künstliche Intelligenz Bürger verwaltet“.


Zusammenfassung Vortrag:

Das Modell als Brückenpfeiler

Von der Skizze der User Interfaces zur strukturierten Information für die Entwicklung

Von: Theresa Kiser, Dominik Gfrärer, Dr. Franziska Gietl

Das Modell als single point of truth

Theresa berichtet davon, dass sie in einem Projekt eine modellbasierte Dokumentation als „single point of truth“ etablieren konnte – wow, Gratulation.
Die Vorstellung, dass alle Projketmitarbeiter, bevor sie etwas tun – erst auf das Modell referenzieren, sich abstimmen und dann loslegen!

Die Aussage – der Code ist die beste verfügbare Dokumentation – hat ausgedient!

Projektbeschreibung/-bestandteile

  • agiles Umfeld
  • Automotivbranche
  • Verkaufstool entwickeln – bestehend aus:
    • Frontend
      • durch Wireframes beschrieben
    • Backend

Was wurde im Projekt mit der Modellierung erreicht?

  • Das Modell ist der zentrale Punkt
    • Es entstand eine gemeinsame und akzeptierte Quelle als sogenannter „single point of truth“ für den Fachbereich und für die Entwicklung
    • Das Modell ist der Brückenpfeiler der Kommunikation – nicht sichtbar, aber tragend
      • Nicht sichtbar bedeutet, dass einzig die Abteilung  Requirements Engineering  das Modell pflegt. Andere Abteilungen, wie die Entwicklung, bekommen Tabellen zur Verfügung gestellt, die auf die Dokumentationsanforderungen der Entwicklung zugeschnitten sind
  • Wiederverwendung von Oberflächenklassen

Wie wurde das erreicht?

  • Einsatz eines UML-Modells
  • zielgruppengerechte Darstellung in Form einer Tabelle. Das Modell war nur für das Requirements Engineering sichtbar.
  • Wireframes und Domänenmodell wurden miteinander verknüpft
  • Modell ist Single Point of Truth
  • Einhaltung der vereinbarten Prozessschritte (das war wohl immer wieder herausfordernd)

Eingesetzter Werkzeugkasten:

  • Domänenklassenmodell
  • Enumerationen
  • fachliche Datentypen
  • Schnittstellenklassen
  • Traces

Warum hat es so gut funktioniert?

  • Effiziente Modellierungstechnik
  • Flexibilität in der Modellierung
  • Einhaltung der vereinbarten Prozessschritte
  • Modell ist Single Point of Truth

 


Weitere Artikel zur REConf 2019 im Netz

Hier findest Du einen Artikel Andrea Herrmann.

Kommentar absenden

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.