Montag, 6. April 2020

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
Requirements-Engineering - Anforderungen identifizieren


Anforderungen an die Aufgabe recherchieren (Generalisierung)


  • Anforderungen aufnehmen und die Grundbegriffe der Fachdomäne und deren Zusammenhänge erarbeiten;
  • Lösungsmöglichkeiten und Alternativlösungen betrachten und analysieren:
    • Wurde dieses oder ein ähnliches Thema bereits erfolgreich umgesetzt? Welche grundlegenden Gemeinsamkeiten und Konzepte können wiederverwendet werden?
    • Wenn es ähnliche erfolgreich umgesetzte Themen gibt, dann gibt es sicherlich auch Negativbeispiele? Was können wir aus diesen Negativbeispielen lernen, um nicht die gleichen Fehler zu begehen?
    • Welche Fachexperten gibt es bei uns im Unternehmen die uns im Bezug auf die Fachdomäne und damit bei der Identifizierung von Heraus- und Anforderung helfen können?
  • Prototypen entwerfen und Alternativlösungen gegenüberstellen (sogenannte Spikes) sind ein probates Mittel um frühzeitig soviel wie möglich über die Anforderungen zu erfahren und diese in Fachkonzepte einfließen zu lassen.
    • Das Ergebnis eines Spikes muss analysiert und dokumentiert werden um daraus zu lernen und Entscheidungen ableiten zu können. Fehler sollen wenn möglich nur einmal begangen werden.
  • Welche Anforderungen und Ergebnisse können in welchem Kontext zusammengeführt, also gemeinsam betrachtet werden (APIs, Design Patterns, Technologien, etc.)?

Anforderungen an die Aufgabe konkretisieren (Spezialisierung)

Anstatt die Anforderung in einem generischen Ansatz lösen zu wollen, empfiehlt es sich die "Spezialfälle" als erstes zu betrachten. In den meisten Fällen lösen mehrere Spezialfälle zugleich den generischen Fall. 
  1. Was ist die Hauptanforderung an einen möglichen Lösungsansatz (Plain Vanilla)? 
  2. Kann diese Hauptanforderung noch weiter zerlegt (die Spezialisierung vertieft) werden?
  3. Welche Fehler können in diesem (Plain Vanilla)-Ansatz auftreten?
  4. Was ist das schlimmste Szenario was im Fehlerfall eintreten kann (Worst-Case-Szenario)?
  5. Mit welchen kritischen Szenarien würden wir uns konfrontiert sehen, wenn wir (die Entwickler) die Anforderung stellen würden? Was würden wir anders machen? Welche Entscheidungen müssten/würden wir überdenken?
    1. Der Perspektivenwechsel ist hier im Design von Oberflächen (GUIs) sehr spannend. Als Entwickler habe ich kein Thema damit, mehrere Buttons hintereinander klicken zu müssen, aber wie sieht das der Endanwender im alltäglichen?
    2. Laufzeiten stören den einzelnen Entwickler während der Entwicklungsphase nicht unbedingt. Als Endanwender können mehrere Sekunden Wartezeit das positive Erlebnis einer neuen Softwareapplikation schnell verkehren.

Der heilige Gral

Softwareentwickler neigen oft dazu, einen Prototypen (womöglich aus einem Spike entstanden) als Einstieg in ein potentielles Produkt zu sehen. Die Vorteile liegen auf der Hand:
  • Stakeholder können sich einen praktischen Eindruck von der meist eher abstrakten Anforderungsbeschreibung verschaffen
  • Der Entwickler erhält einen Vertrauensvorschuss ("das Meiste ist ja schon erledigt“)

Leider kann dieser Ansatz schnell in einer Sackgasse enden, da nicht alle Risiken und Unwägbarkeiten erfasst wurden. Wenn erst alle Risiken abgeschätzt und die komplexen Anforderungen erfüllt werden, wird ein "vorzeigbares" Ergebnis für den Stakeholder viel später vorliegen aber dafür sind alle Unwegsamkeiten bereits gelöst.


Vor dem Beginn einer Realisierung sollte unabhängig für welchen Weg sich entschieden wird geklärt sein: Welche Risiken und Unwegsamkeiten liegen vor und welche Lösungsstrategien versprechen Abhilfe!

Keine Kommentare:

Kommentar veröffentlichen

Erfahrungen & Bewertungen zu yourIT GmbH