Requirements-Engineering - Designmethoden

Wie können wir aus groben Zielen und Vorgaben die Granularität von Anforderungen verfeinern und dabei Geschäftsprozesse (Use Cases) untersuchen? Wenn wir in der Softwareentwicklung über fachliche Anforderungen sprechen wollen, sprechen wir am Besten in der Sprache der Fachexperten. In der Sprache des Kunden! Dafür müssen Entwickler, Product Owner und Projektleiter die Fachsprache erlernen. Dieser Ansatz nennt sich Domain-Driven-Design (DDD).

Domain-Driven-Design (DDD) - Modellierung nach Fachlichkeit

Der Grundsatz dieser Methode lässt sich kurz zusammenfassen: "Wir konzentrieren uns ausschließlich auf den fachlichen Teil eines Themas und nicht auf mögliche technische Lösungen." Als Hilfsmittel zur Modellierung sei hier auf das Domain Storytelling verwiesen!

Was sind eigentlich die Vorteile des DDD?

• Die Kommunikation zwischen Fachexperten und Entwicklerteam ist frei von Störungen, denn es kann direkt über Prozesse, Abläufe oder Funktionen eingestiegen werden
• Fachexperten können Ihre Anforderungen präziser formulieren, da sie sich in ihrer Fachdomain befinden

Requirements-Engineering - Designmethoden

Requirements-Engineering - Anforderungen identifizieren

In der objektorientierten Programmierung gibt es zwei Begrifflichkeiten, die jeder kennen sollte: Generalisierung und Spezialisierung (Vererbung).

Alle Gemeinsamkeiten eines Objektes werden ermittelt und in der Basisklasse beschrieben (Generalisierung). Die eigentliche Implementierung erfolgt in einer abgeleiteten Klasse (Spezialisierung). Daraus schließen wir:

Requirements-Engineering - Anforderungen identifizieren

Anforderungen an die Aufgabe recherchieren (Generalisierung)

Automatisierte Releasenotes - Transparenz in die Tiefe

Wer kennt sie nicht die ewigen Fragen: "Was sind die Highlights im aktuellen Release?" oder "Welche Bugfixes/Improvements konnten in das Release einfließen?"

Agiles arbeiten und der damit vermeintlichen Transparenz gegenüber Product-Owner, Stakeholder oder allgemein dem Management trotzt eine Phase des Requirements-Engineering, ja gar einer kompletten Iteration.

Es werden Anforderungen der Product-Owner und Stakeholder ermittelt, aufgenommen und aufbereitet (Requirements-Engineering). Es werden Priorisierungen des Backlogs, Sprintbacklogs und des Sprintlogs selbst durchgeführt. Am Ende steht die Frage in fast jedem Review-Meeting: "Welche dieser hier gezeigten Tickets werden in das kommende Release einfließen?". Dem Releasemanager drehen sich förmlich im Ansatz der zu erwartenden Frage die Fußnägel auf. Allerdings formuliert sich die Antwort auf die zu erwartende Frage schon, obwohl die eigentliche Frage noch überhaupt nicht gestellt worden ist: "Wozu führen und managen wir Komponenten und Versionen in unserer Planungs- und Releasephase?" 

Da sich diese Frage immer wieder stellt, haben wir uns als Software-Entwickler der yourIT dieser ewigen und immer wiederkehrenden Aufgabe gestellt. Als Ergebnis haben wir ein Maven-Plugin geschrieben, welches beim Bauen des Artefaktes die Releasenotes aus unserem Jira-Board abgreift, als HTML-Report aufbereitet und ins gebaute Artefakt mit einbaut. 

Im einfachsten Fall kann dieser Report im Review-Meeting herangezogen werden, da alle Tickets und Anforderungen, die gelöst wurden, darin aufgelistet sind. Im komplexeren Anwendungsfall werden die generierten Releasenotes automatisiert im Buildprozess eingepackt und sind für den Kunden jederzeit einsehbar.

Wie kompliziert ist das und was benötigen da jetzt genau?

Alles, was in der Maven-Konfiguration benötigt wird, ist ein von der yourIT geschriebenes Maven-Plugin:

<build>
  ...
    <plugin>
      <groupId>de.yit.yourit.maven.jira-releasenotes</groupId>
      <artifactId>jirareleasnotes-maven-plugin</artifactId>
      <version>1.0.0</version>

      <executions>
  <execution>
    <goals>
      <goal>jira-releasenotes</goal>
    </goals>
    <phase>compile</phase>
 </execution>
      </executions>
      <configuration>
  <jpql>component = "yourIT Webseite" and ..."</jpql>
  <jiraURL>http://0.0.0.0:8080</jiraURL>
  <username>jenkins</username>
  <password>*****</password>
  <target>${project.build.outputDirectory}/static/notes.html</target>
       </configuration>
    </plugin>

  ...

</build>

Im Buildprozess sieht es sehr unspektakulät aus:

[INFO] --- jirareleasnotes-maven-plugin:1.0.0:jira-releasenotes 

(default) @ website-app ---

Aber das Ergebnis ist dennoch Aussagekräftig:

ReleaseNotes - Report

Verantwortlich für diesen Beitrag: yourIT GmbH, Balingen, Zollernalbkreis