Regelwerk

Manchmal ist es sehr wichtig, die Dinge auch begrifflich gut auseinanderzuhalten. Kürzlich wollte ich erklären, dass Requirements nicht mit Business Rules zu verwechseln sind, und kam dabei gelinge gesagt ins Schwimmen. Requirements sind keine Business rules und umgekehrt. Schliesslich habe ich eine sehr brauchbare Zusammenstellung von James Taylor gefunden, der das auf seinem Blog Enterprise Decision Management zusammengefasst hat.
Requirements sind vollständig von den Prozessen der Ableitung und Umsetzung konkreter Regeln zu trennen. Sie sind Vorarbeiten, die die Bedingungen und Grundlagen künftiger Regeln zusammentragen: Zum Beispiel welche Regeln sind bereits in den Tiefen des Codes verboren? Wie lassen sie sich zuorden - sprich wer sollte sie definieren? Welche Geschäftsprozesse können oder sollten eigentlich automatisierbar werden. Oder ganz entscheidend, welche Ziele sollen die regelbasierten Anwendungen umsetzen? All das wird neben den konkreten Anforderungen in den Use Cases als Requirements für die Erstellung der Regeln zusammengefasst.

1. Brainstorming - Wird gemeinhing als ein sehr effektiver Weg aufgefasst, versteckte Regeln aufzuspüren bzw. zu klassifizieren.
2. Dokumentenanalyse - Das Durchforsten bestehender Regelwerke wie Handbücher, Vorschriften etc. nach Regeln und Ableitungen.
3. Zielgruppe - Wer wird die jeweiligen Regeln künftig benutzen und vor allem verwalten? Diese künftigen Anwender können hervorragenden Input für die Erarbeitung von Regelvorgaben geben.
4. Schnittstellenanalyse - In Anlehung an den letzten Artikel über Interaction Design sollte dieser Punkt bei der Entwicklung von Benutzerschnittstellen für die Verwaltung der Business Rules nicht vernachlässigt werden.
5. Gespräche und Interviews - Sie sollen das eigentliche Expertenwissen extrahieren, das automatisiert werden kann bzw. abgeleitet werden sollte. Einer der wichtigen Bedingungen bzw. Anforderungen für das Aufstellen automatisierbarer Geschäftsregeln.
6. Beobachtungen - Sie geben Einsicht in die tatsächlichen Prozesse, wie in einem Unternehmen Entscheidungen entwickelt, getroffen und eingehalten werden. Mit Hilfe von Beobachtungen lassen sich ausserdem Entscheidungen aufspüren, die automatisierbar sind, welche Prozesse vollkommen geschlossen (sprich ohne Eingriffe) ablaufen, oder ob Prozesse unterbrochen werden (und wenn ja warum, durch wen etc.)
7. Prototypen - Ist zwar nicht direkt für die Ableitung von Regeln nötig als vielmehr in der Entwicklungsphase für das Interaction Design. Als Überprüfung, wie gut die künftigen Anwender mit der Oberfläche zurechtkommen, ist es ein guter Zwischenschritt der Entwicklungsphase.
8. Requirements Workshops - Anscheinend werden Regeln immer wieder gefunden, wenn es eigentlich die Diskussion ihrer Vorbedingungen geht. D. h. Workshophs sind eigentlich eine Alternative zu den o. g. Brainstorming- oder Interviewveranstaltungen.
9. Reverse Engineering - Als Technik der Dekonstruktion bestender Systeme können verborgenen Strukturen sichtbar gemacht werden und damit gleichfalls im Code/System versteckte Regeln. Fast jedes systematische Reverse Engineering befördert solche “kleinen” Geheimnisse an Regelwerk zu Tage, die nicht wirklich technische als vielmehr Geschäftsregeln sind. Reverse Engineering hilft, diese meist in Vergessenheit geratenen Regeln aus dem System zu fischen.

Zum Thema Requirements und Use Cases versus Business Rules sei noch ein Buch empfohlen: Dave Kulak, Use Cases: Requirements in Context.
Es verfolgt den Ansatz konsquent, die Anforderungen streng von den Geschäftsregeln selbst zu trennen.