Suche
Kolumne

Knigge für Softwarearchitekten: Schlechte Requirements? Handeln statt jammern!

Peter Hruschka, Gernot Starke

Immer wieder jammern Kunden, dass Systeme schlecht seien und die IT die Anforderungen überhaupt nicht erfüllt habe. Entwicklungsteams verteidigen sich damit, dass ihnen niemand gesagt hat, was das Produkt wirklich können soll. Sie schieben die Schuld auf schlechte Anforderungen. Hätte man diese Wünsche rechtzeitig und klar geäußert, dann wäre die Lösung auch skalierbar, erweiterbar, performant und sicher. Fachbereiche oder Marketingabteilungen kontern: Es war doch klar, dass wir nach dem europäischen auch den asiatischen Markt erobern wollen. Selbstverständlich muss das Produkt leicht an neue Gesetze, Standards und Normen adaptiert werden können. Warum hätten wir das explizit sagen sollen?

Auch wenn wir heute zum Glück die leidigen Wasserfallprojekte hinter uns gelassen haben –haben wir? –, so gilt weiterhin eine Aufgabentrennung zwischen Beteiligten. Architekten und Entwicklungsteams verantworten hauptsächlich die Lösungen von Problemstellungen. Die Problemstellung in Form von mehr oder weniger präzisen Anforderungen sollte als Input für die Architekturarbeit vorhanden sein. Wir wissen seit Langem, was zu einer guten Requirements-Spezifikation gehört [1].

Im Wesentlichen sind das die treibenden Kräfte für Projekte und Produktentwicklung: Die Ziele oder die Vision, wo wir hinwollen, die Mitspieler (neudeutsch: Stakeholder), denn sie sind die Quellen für alle Wünsche und Anforderungen, sowie die Festlegung des Scopes (Kontext), denn unsere Spielwiese ist nicht beliebig groß. Teams sollten wissen, was sie gestalten dürfen, wovon sie die Finger lassen müssen und welche Dinge außerhalb ihres Einflussbereichs liegen. Außerdem müssen Teams die gewünschte Funktionalität des Systems sowie die Prozesse und Aufgaben kennen, die ein System unterstützen soll. Dazu gehören auch die Daten und Informationen, die das System verwalten und verarbeiten muss. Last but not least müssen sie die gewünschten Qualitäten kennen und alle technologischen und organisatorischen Randbedingungen, die sie bei der Entwicklung oder Weiterentwicklung einhalten müssen. Wir betrachten, wie Input heute typischerweise für Entwicklungsprojekte vorliegt.

Der (traurige) Stand der Praxis

Wir beide sind geteilter Meinung, wie gut oder schlecht unsere Branche heute in Bezug auf die Vorgabe guter Anforderungen ist. Die folgende Tabelle ist ein Kompromiss zwischen Peter, der die Anforderungswelt etwas positiver sieht, und Gernot, der oft noch viel Schlimmeres in Projekten erleben musste. Übersichten schlimmer Anforderungsfehler haben wir zusammengestellt („Common Requirement Problems“ & „10 Requirement Traps to Avoid„.

Benötigt In der Realität vorhanden
Projekttreiber Projektziele meist implizit bekannt 😃
Stakeholder oft unvollständig, nicht schriftlich 😐
Kontextabgrenzung (Scope des Systems) gar nicht oder unvollständig 😦
Funktionale Anforderungen Funktionen und Abläufe recht gut vorgegeben, meist jedoch umgangssprachlich 😃

ohne präzisere Modelle 😐

Daten oft implizit, ohne klare Definition 😐
Nicht funktionale Anforderungen Qualitätsanforderungen fehlen oft 😦, falls vorhanden, dann oft lückenhaft
Randbedingungen oft bekannt, aber Hörensagen 😃

Tabelle 1: Stand der Praxis bei zentralen Requirements-Themen

Der miserable Zustand vieler Anforderungen nervt gewaltig. Wir sollen unter Zeitdruck großartige Systeme bauen, aber unsere Auftraggeber oder andere Beteiligte möchten die Zeit für vernünftige Anforderungen am liebsten nicht investieren, weil „das ja alles ohnehin klar sein müsste“. Mitnichten, liebe Business-Stakeholder und Fachabteilungen, vielmehr startet nun folgender Teufelskreis:

  1. Entwicklungsteam bekommt schlechte Anforderungen.
  2. Weil viele Dinge noch unklar sind, implementiert das Team eine flexible oder generische Lösung. Das dauert länger als geplant. Zusätzlich wird Code umfangreicher und komplexer als er hätte sein müssen.
  3. Fachabteilung schimpft über Entwicklungsteam.
  4. Goto 1.

Gruppenreise ohne Ziel

Softwareentwicklung ohne vernünftige Vorgaben ist etwa genauso unproduktiv wie eine Gruppenreise ohne klar definiertes Reiseziel. Alle Beteiligten stehen am Ausgangspunkt und lamentieren darüber, wie und wohin es gehen sollte, könnte oder müsste. Falls Sie mal versucht haben, mit mehr als zehn Personen ein Restaurant zum gemeinsamen Mittagessen auszusuchen, wissen Sie, was wir meinen. Die Anzahl der Meinungen ist in der Regel größer als die Anzahl der Beteiligten. Was Sie als Architekten und Entwickler im Fall unklarer oder schlechter Anforderungen tun sollten, nennen wir intelligent raten und aktiv Feedback einholen. Sie kennen sich in der Regel zumindest halbwegs mit der Materie, der Domäne und dem allgemeinen Umfeld aus. Damit sind Sie oder das Team durchaus in der Lage, explizite Annahmen (educated guesses) zu formulieren. Schreiben Sie diese Annahmen auf und beschaffen Sie sich dazu das Feedback der Anwender, Fachabteilungen oder Business-Stakeholder. Unserer Erfahrung nach führt diese Feedbackschleife recht schnell zu besseren Anforderungen. Der Preis dafür: Sie als Architekten oder Entwickler müssen etwas Zeit und Hirn investieren sowie ein paar methodische Grundlagen berücksichtigen.

W-JAX
 
Arno Haase

Neues aus der Java-Trickkiste

mit Arno Haase (Arno Haase Consulting)

Norman Lahme-Hütig

Java-8-Nachlese – Wie hat Java 8 die Java-Welt verändert?

mit Klaus Kreft (Angelika Langer Training/Consulting)

Kontext First

Zuerst sollten Sie den Kontext Ihres Systems klären und damit dessen externe Schnittstellen festlegen. Wir haben im Dschungel realer Projekte gelernt, niemals ohne Kontextabgrenzung an der Entwicklung von Systemen zu arbeiten. Unserer Erfahrung nach kommen insbesondere bei externen Schnittstellen die gefährlichen impliziten Annahmen zum Tragen, die später im Produktivbetrieb dann ihre verheerende Wirkung in Form von Prio-1-Fehlern und schmerzhaften Eskalationen zeigen.
Dabei kann Kontextklärung so einfach sein: Ein simples Diagramm ergänzt um eine kleine Tabelle mit den Beschreibungen der externen Schnittstellen können Sie in kurzer Zeit fertigstellen und über die gesamte Entwicklungs- oder Lebenszeit des Systems kontinuierlich weiterpflegen. Dazu können Ihnen wesentliche Stakeholder in minutenschnelle konstruktive Rückmeldung geben. Ein Beispiel finden Sie in Abbildung 1.

Abb. 1: Beispiel einer Kontextabgrenzung

Abb. 1: Beispiel einer Kontextabgrenzung

Qualität konkretisieren

Neben fehlendem Kontext schmerzt uns als Architekten am meisten der oft miserable Zustand von Qualitätsanforderungen: Alle Stakeholder erwarten implizit gute Qualität, aber was das für das System genau sein soll, bleibt implizit und im Dunkeln. Also kümmern Sie sich nach der Kontextklärung um Qualitätsanforderungen. Nutzen Sie dazu Qualitätsbäume und Szenarien. Das sind einfache, pragmatische, aber hochgradig wirkungsvolle methodische Mittel dazu. Unser konkreter Vorschlag: Sammeln Sie mal die Themen (Qualitätsmerkmale), die überhaupt für Ihr System relevant sind, und priorisieren Sie sie. Einen guten Ausgangspunkt bietet das ISO-25010 Qualitätsmodell oder die Kapitel 10 bis 17 im Volere Requirement Specification Template. Ergänzen Sie detaillierte Szenarien, die konkrete Erwartungshaltungen an das System beschreiben. Unserer Erfahrung nach verstehen praktisch alle Stakeholder solche Szenarien sofort und können gute Rückmeldung dazu geben. Ein kleines Beispiel finden Sie in Abbildung 2. Sie finden auf Github dutzendweise konkrete anonymisierte Beispiele aus realen Systemen.

Abb. 2: Beispiel konkreter Qualitätsanforderungen

Abb. 2: Beispiel konkreter Qualitätsanforderungen

Architekten und Entwickler als Innovatoren

Als Requirements und Architektur noch Phasen in Projekten waren, ging man davon aus, dass das Business (Fachabteilungen, Kunden, Product Owner, Marketing zusammen mit Analytikern) die Vorgaben macht und ein IT-Entwicklungsteam diese Vorgaben danach umsetzt. Im Grunde ist das o.k., denn IT sollte das Business unterstützen. Oft haben Techies viel bessere Kenntnisse über neue Technologien, die dem Business Dinge ermöglichen, die bisher gar nicht vorstellbar waren. Deshalb sollten sich Entwickler und insbesondere Architekten auch bei der Ausgestaltung von Anforderungen und bei der Ausarbeitung von alternativen Businesslösungen aktiv einbringen.

Wir wissen heute, dass Auftraggeber und Auftragnehmer in etwa im gleichen Tempo lernen, was wirklich für das Business gebraucht wird [2]. Manchmal kennt das Business den Bedarf besser, manchmal haben Architekten mehr Einsichten und Erfahrungen, um das Business durch innovative Lösungen voranzubringen. Durch gemeinsames Schaffen und Verbessern von Anforderungen und Lösungen sowie durch gezielte Wechselwirkungen zwischen Requirements und Architektur kommen Sie am ehesten zu marktgerechten, kundenfreundlichen und gewinnbringenden Produkten oder Systemen.

Fazit

Klagen Sie als Architekt weniger über mangelhafte, schlecht dokumentierte Requirements. Nehmen Sie diesen Teil Ihres Schicksals in die eigene Hand und klären Sie Anforderungen. Gehen Sie auf Marketing, Businessanalysten, Product Owner, Produktmanager und andere relevante Stakeholder proaktiv zu. Helfen Sie ihnen, zu angemessenen Zeitpunkten festzulegen, was Sie oder Ihre Teams als Basis für Entwurfsentscheidungen dringend benötigen. Konzentrieren Sie sich dabei insbesondere auf konkrete Qualitätsanforderungen – am besten durch Szenarien untermauert – und schaffen Sie mit expliziter Kontextabgrenzung klare Absprachen an den externen Schnittstellen Ihres Systems.

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.