IT-Projekte werden zunehmend komplexer. Meist ist den Entwicklern nicht einmal mehr klar, welche Anforderungen der Kunde momentan noch stellt, von welchen Anforderungen er abgewichen ist.

Das führt unter anderem dazu, dass beim Einbauen einer neuen Funktion in die Software gegen geltende Anforderungen verstoßen wird. Ein Beispiel:

Beispiel 1: Einfärbung der Kunden
Die Anforderung des Kunden: Jeder Kunde soll eingefärbt werden: Schwarz für normal, Gelb mit Zahlungsverzug und Rot mit eingestellter Leistung. Fordert er jetzt eine neue Funktion wie z.B. eine Statistik aller Kunden, muss die Anforderung umgesetzt werden.

Beispiel 2: Erfassung des Geburtsdatums
Der Kunde wollte in der Anfangsplanung das Geburtsdatums jedes Kunden erfassen. Da nach der neuen DSGVO eine Speicherung nicht für die Geschäftsbeziehung notwendig ist, müsste eine Genehmigung eingeholt werden. Um den Aufwand einzusparen, wird das Geburtsdatum gestrichen. Die Anforderung hat sich geändert.

Beispiel 3: Zugriffskontrolle
Die Anforderung des Kunden ist, alle Zugriffe von Mitarbeitern zu protokollieren und Zugang zu abrechnungsrelevanten Bereichen nur für Buchhaltungs-Mitarbeiter zu erlauben. Beim Umsetzen des neuen SEPA-Einzugs darf der Programmierer die Programmierung Protokollierung nicht vergessen und auch Zugriffsprüfungen einprogrammieren.

Kunden-Anforderungen in einer Programmiersprache niederschreiben

Der Ansatz von Requirement Oriented Programming ist nun, die Anforderungen des Kunden zuerst einmal formal niederzuschreiben.

Die Software soll dann automatisch daraus entstehen. Anstatt dass der Programmierer anhand der Anforderungen eine Software programmiert, muss er Regeln aufstellen, wie die Anforderungen in Software umgewandelt werden. Dadurch kann er flexibel auf Änderungen der Anforderungen oder Kombination von Anforderungen reagieren. Die Software wird dann einfach neu generiert, ändern sich die Anforderungen.

Die Vorteile liegen auf der Hand:

• Der Software-Erstellungsprozess ist besser dokumentiert
• Die Software ist bei vorhandenem Regelsatz schneller programmiert
• Typische Programmierfehler werden vermieden
• Man kann schnell auf komplexe Änderungen der Anforderungen reagieren
• Es lassen sich Produktvarianten mit variierenden Anforderungen bereitstellen