Architekturänderungen durch Prototyping vermeiden

Ist man mit einem Kunden in einem Vertragsverhältnis für Individualsoftware, so kann es sein, dass man am Anfang ein SRS bekommt, um Verträge aufzusetzen.

Was ist ein SRS?

SRS ist die Abkürzung für Software Requirements Specification. Ein SRS ist ein umfassendes Dokument, das genau beschreibt, was ein Software-System tun soll und wie es sich verhalten muss. Es dient als vertragliche Grundlage zwischen dem Auftraggeber (Kunde) und dem Auftragnehmer (Entwicklerteam). Es enthält Functional Requirements. Beispiele sind:

• “Der Benutzer muss sich mit E-Mail und Passwort einloggen können.”
• “Das System muss beim Checkout automatisch die Mehrwertsteuer berechnen.”
• “Ein Klick auf ‘Drucken’ generiert ein PDF.”

Es beinhaltet auch Nicht-funktionale Anforderungen, welche das WAS noch untermauern.

Was ist ein SDD?

Das Software Design Document (SDD) ist der technische Bauplan der Software. Während das SRS (Pflichtenheft) das WAS beschreibt, liefert das SDD die detaillierte Antwort auf das WIE. Es richtet sich primär an die Softwareentwickler und Architekten, nicht mehr an den Endkunden.

Ich muss aber gestehen, dass ich es schon lange nicht mehr gesehen habe. In der agilen Welt bedient man sicher anderer Vehikel.

Der Agile Ansatz

In der agilen Welt spricht man (u.a.) von der evolutionäre Softwarearchitektur. Man fährt in diesem Fall nur auf Sicht (natürlich bestimmt das Risiko die Sicht) und baut keine Dinge, die keine aktiven Anforderungen haben. Welche Herausforderungen lauern hier?

Vorweg: IKIWISI (“I Know It When I See It”). Es beschreibt eines der fundamentalsten Probleme in der Softwareentwicklung: Menschen sind extrem schlecht darin, sich abstrakte Dinge vorzustellen, aber sehr gut darin, auf Sichtbares zu reagieren. Und das genau will ich mit diesen beiden Booten beschrieben:

• Rechts: Man macht zuerst Mockups und versucht durch maximale Customer-Interaktion möglichst viel herauszukitzeln. Im Requirements Engineering kennt man den Begriff Prototyping. Dadurch kann man - schnell wie ein kleines Boot - auf Kursänderungen reagieren.
• Links: man entwickelt Features Ende zu Ende. Dadurch hat man zwar eine “echte” Experience – aber: Änderungen sind dadurch schwieriger zu realisieren - das Manövrieren eines Tankers ist viel “zäher”" als mit einem Speedboot.

Zu erwähnen: Das trifft sicher nicht auf jedes Projekt zu – aber bei stark Customer-Facing Lösungen bekommt es an Relevanz.

Warum ist der linke Ansatz so interessant? Kommunikation mit Umsystemen lassen sich leicht simulieren. Dadurch kann man sehr schnell Szenarien durchspielen und wird dadurch schnell in die Situation kommen, in der sich die Frage stellt: “Was passiert aber, wenn X eintritt?”

Fazit: Das WAS und WIE sind zwei unterschiedliche Welten und sollten stets so gut wie geht erforscht werden. Architekturumbauten sind meist schwergewichtig.