CRUD-Matrix
Die CRUD-Matrix ist eine Tabelle, die die Prozesse eines Systems mit seinen Datenentitäten kreuzt. Die Prozesse oder Anwendungsfälle bilden die Zeilen. Die Entitäten bilden die Spalten. Jede Zelle hält fest, was der Prozess mit der Entität tut: sie erstellen (C), lesen (R), ändern (U) oder löschen (D). Danach liest die Analystin die Spalten. Daten ohne Ersteller, Daten ohne Leser und Daten mit zwei Erstellern weisen je auf eine fehlende Anforderung oder einen Mangel der Datenqualität hin.
Zweck
Die CRUD-Matrix prüft, ob die Prozesse eines Systems seine Daten abdecken. Das Anwendungsfallmodell beschreibt, was die Akteure tun. Das Datenmodell beschreibt, was das System speichert. Jedes der beiden Modelle kann für sich vollständig wirken. Das Raster stellt sie Zelle für Zelle einander gegenüber. Es zeigt die Lücken, bevor das Team die Anforderungen festschreibt: eine Entität, die niemand erstellt, einen Anwendungsfall, der nie erfasste Daten liest.
Das Ergebnis umfasst das ausgefüllte Raster und die Liste der Befunde. Jeder Befund geht von einer Lücke oder einer Doppelung im Raster aus. Er wird zu einer Frage an den Fachbereich und danach zu einem zusätzlichen Anwendungsfall, einer präzisierten Anforderung oder einer aus dem Modell entfernten Entität.
Auf der Ebene eines Anwendungsportfolios gruppiert dasselbe Raster Prozesse und Daten zu Teilsystemen. In der Wartung listet die Spalte einer Entität die Prozesse auf, die eine Änderung dieser Entität berührt.
Einsatz
Wann sie einzusetzen ist
- Anwendungsfälle und Datenmodell liegen vor: vor der Validierung der Anforderungen prüfen, ob sie sich gegenseitig abdecken.
- Vollständigkeitsprüfung eines Pflichtenhefts: die Entität ohne Ersteller und den vergessenen Prozess finden.
- Daten, die mehrere Anwendungen teilen: die Doppelungen erkennen, die entstehen, wenn zwei Systeme dieselbe Entität erstellen.
- Aufteilung eines Systems oder eines Portfolios: Prozesse und Daten zu Teilsystemen gruppieren.
- Änderung einer Entität in der Wartung: die Prozesse auflisten, die zu analysieren und erneut zu testen sind.
- Releaseplanung: den Prozess, der Daten erstellt, vor den Prozessen ausliefern, die sie lesen.
- Personendaten im Modell: jedes erhobene Datenelement mit mindestens einem Prozess begründen, der es liest.
Wann sie nicht einzusetzen ist
- Weder Prozessliste noch Datenmodell: zuerst die Datenmodellierung durchführen und die Anwendungsfälle schreiben. Ohne sie hat das Raster keine Achsen.
- Frage der Berechtigung: Welche Rolle handeln darf, klärt die Rollen- und Berechtigungsmatrix.
Beschreibung
Zeilen, Spalten und Buchstaben
Die Zeilen sind die Geschäftsprozesse oder Anwendungsfälle des Systems. Eine Zeile nennt ein Ziel des Akteurs ("Hund anmelden").
Die Spalten sind die Entitäten des Entity-Relationship-Diagramms oder die Klassen des Klassendiagramms. Eine Spalte pro fachliche Entität genügt. Technische Tabellen (Protokolle, Zuordnungstabellen) bleiben ausserhalb des Rasters.
Jede Zelle enthält keinen, einen oder mehrere Buchstaben. C hält fest, dass der Prozess eine Instanz der Entität erstellt. R steht für das Lesen, U für das Ändern und D für das Löschen. Die Buchstaben sind die englischen Anfangsbuchstaben von Create, Read, Update und Delete. Eine leere Zelle sagt, dass der Prozess die Entität nicht berührt. Die Legende legt die lokalen Konventionen fest, etwa ob ein U das vorangehende R einschliesst.
Woher das Raster stammt
Der Leitfaden Business Systems Planning von IBM (1978) stellt die Datenklassen den Prozessen des Unternehmens gegenüber. Er trägt nur zwei Buchstaben ein: C für den Prozess, der die Daten erstellt, U für den Prozess, der sie nutzt. Der Leitfaden liest aus diesem Raster, wie die Prozesse Daten teilen. Daraus leitet er die Informationsarchitektur ab.
Information Engineering ist eine datenzentrierte Methode für den Entwurf von Informationssystemen. Sie verbreitete sich in den 1980er-Jahren und zu Beginn der 1990er-Jahre. Laut Politano liefert ihr strategischer Informationssystemplan die CRUD-Matrix zusammen mit dem Datenmodell und der funktionalen Dekomposition.
Der BABOK widmet der Form Prozesse × Entitäten keine eigene Technik. Sein Glossar definiert die CRUD-Matrix über Rollen: welche Benutzerrollen welche Entitäten erstellen, lesen, ändern oder löschen dürfen. In einem Satz räumt es danach ein, dass dasselbe Raster statt der Benutzer auch Prozesse zeigen kann.
Das Raster aufbauen
- Prozesse oder Anwendungsfälle auf Zielebene auflisten. IBM ordnet sie nach dem Lebenszyklus der Ressource, die sie verwalten. Der Prozess, der Daten erstellt, steht dann vor den Prozessen, die sie lesen.
- Entitäten aus dem Datenmodell auflisten. Fügt die Analystin in diesem Schritt eine Entität hinzu, trägt sie diese auch ins Datenmodell ein. Sonst laufen die beiden Dokumente auseinander.
- Zeile für Zeile ausfüllen. Für jeden Anwendungsfall die Schritte des Hauptszenarios und der Alternativszenarien erneut lesen. Jede Entität notieren, die der Schritt erstellt, liest, ändert oder löscht. Eine Zeile in einem Zug ausfüllen. Eine leere Zelle in einer ausgefüllten Zeile bedeutet dann "keine Operation".
- Das Raster lesen: zuerst Spalte für Spalte, dann Zeile für Zeile. Jede Auffälligkeit wird zu einem Befund an den Fachbereich.
Neben jeden Buchstaben schreibt die Analystin die Nummer des Schritts, der ihn begründet. Bestreitet eine Prüferin ein R, findet sie über diese Nummer den Schritt im Szenario.
Die Matrix lesen
Der Wert des Rasters liegt in seinen Lücken. Politano nennt die Grundprüfungen: Eine Entität trägt in der Regel mindestens ein C und mehrere R. Mehrere C auf derselben Entität weisen auf ein mögliches Problem der Datenqualität hin.
- Eine Spalte ohne C. Kein Prozess im Projektumfang erstellt die Entität. Entweder fehlt ein Anwendungsfall oder die Daten stammen aus einem anderen System. Im zweiten Fall muss die Schnittstellenanalyse dieses System und den Datenfluss benennen.
- Eine Spalte ohne R. Das System erfasst Daten, die niemand nutzt. Entweder fehlt ein verwendender Prozess oder die Daten sind zu entfernen. Bei Personendaten ist die Frage auch eine rechtliche: Das DSG (Art. 6 Abs. 3) erlaubt die Beschaffung nur zu einem bestimmten und für die betroffene Person erkennbaren Zweck. Die kantonalen Gesetze stellen für eine Gemeinde denselben Grundsatz auf.
- Eine Spalte ohne U. Kein Prozess hält die Entität aktuell. Entweder fehlt ein Änderungsfall (der Adresswechsel des Halters) oder die Daten bleiben nach der Erfassung unverändert.
- Eine Spalte mit mehreren C. Zwei Prozesse erstellen dieselbe Entität nach Regeln, die oft voneinander abweichen. Der Fachbereich bestimmt die massgebende Quelle. Die übrigen Prozesse lesen oder ändern.
- Eine Spalte ohne D. Kein Prozess beendet das Leben der Daten. Der Fachbereich legt ihre Aufbewahrungsdauer fest und bestimmt den Prozess, der sie anwendet. Bei Personendaten verlangt das DSG (Art. 6 Abs. 4) ihre Vernichtung oder Anonymisierung, sobald sie nicht mehr nötig sind.
- Eine leere Zeile. Der Prozess berührt keine Daten des Modells. Entweder lässt das Datenmodell eine Entität aus oder der Prozess liegt ausserhalb des Projektumfangs.
Prozesse und Daten zu Teilsystemen gruppieren
Der Leitfaden von IBM leitet aus dem Raster auch die Architektur ab. Die Analystin ordnet die Spalten neu: Die Daten, die der erste Prozess erstellt, rücken nach links, danach jene des nächsten Prozesses. Die C liegen dann auf einer Diagonale. Die Analystin umrahmt jede Gruppe von Prozessen samt den Daten, die sie erstellen: Jeder Rahmen grenzt ein Teilsystem ab. Ein U ausserhalb seines Rahmens zeigt einen Datenfluss zwischen zwei Teilsystemen. Der Leitfaden zeichnet diesen Fluss als Pfeil. Politano nennt diese Sortierung ein Affinitäts-Clustering über Zeilen und Spalten.
Das Raster in Wartung, Schätzung und Releaseplanung nutzen
Politano zählt die Auswirkungsanalyse und die Schätzung zu den Verwendungen des Rasters. Eine Schätzmethode gibt er nicht an. Für die Auswirkungsanalyse listet die Spalte der geänderten Entität die Prozesse auf, die zu analysieren und erneut zu testen sind. Für die Schätzung gewichtet die Analystin jeden Buchstaben und summiert die Gewichte der Zeile. Die Organisation kalibriert diese Gewichte an ihren früheren Projekten. Keine Norm legt sie fest.
Das Raster ordnet auch die Auslieferungen. Ohne Datenmigration lässt sich ein lesender Anwendungsfall erst durchgängig testen, wenn der erstellende Anwendungsfall ausgeliefert ist.
Die Abgrenzung zur Rollen- und Berechtigungsmatrix
Dieselben vier Buchstaben füllen ein anderes Raster: die Rollen- und Berechtigungsmatrix. Sie kreuzt die Funktionen einer Lösung mit den Rollen, die sie nutzen. Ihre Zelle legt fest, was eine Rolle tun darf. Die CRUD-Matrix kreuzt Prozesse mit Entitäten. Ihre Zelle stellt fest, was ein Prozess mit Daten tut. Die erste Matrix liefert Anforderungen an die Zugriffskontrolle. Die zweite liefert Befunde zur Vollständigkeit.
Der BABOK verwendet für beide denselben Namen. Seine Technik der Rollen und Berechtigungen verweist für die Rollen von IT-Systemen auf eine "CRUD-Matrix". Der Titel eines Rasters verrät also nicht, welches man vor sich hat. Seine Achsen verraten es.
| Matrix | Zeilen × Spalten | Was eine Zelle sagt | Entschiedene Frage | Ergebnis |
|---|---|---|---|---|
| CRUD | Prozesse oder Anwendungsfälle × Datenentitäten | die Operation, die der Prozess ausführt | decken die Prozesse die Daten ab? | Befunde zur Vollständigkeit |
| Rollen und Berechtigungen | Funktionen der Lösung × Rollen | das Recht, das das System der Rolle gewährt | wer darf im System handeln? | Anforderungen an die Zugriffskontrolle |
Im Softwareentwurf bezeichnet CRUD auch die Grundoperationen einer Datenbank oder einer API. Die Matrix entlehnt diese Buchstaben für die Analyse von Anforderungen.
Die Fallstricke
CRUD-Anwendungsfälle
Zeilen wie "Hund erfassen", "Hund ändern" und "Hund löschen" ergeben ein Raster, in dem jede Zeile einen einzigen Buchstaben in einer einzigen Spalte trägt. Dieses Raster bestätigt den Zuschnitt und prüft nichts. Die Analystin schreibt den Anwendungsfall auf der Ebene des Akteursziels und baut danach das Raster.
Das R überall
Notiert die Analystin überall dort ein R, wo ein Bildschirm die Daten anzeigen könnte, füllt sie alle Spalten. Die Prüfung auf eine Spalte ohne R schlägt dann nie mehr an. Ein R gehört in die Zelle, wenn ein Schritt des Szenarios die Daten verwendet.
Das Raster aus dem Gedächtnis
Aus den Namen der Anwendungsfälle gefüllt, spiegelt das Raster die Intuition der Analystin. Aus den Schritten der Szenarien gefüllt, zeigt es, was die Texte auslassen.
Der Befund ohne Adressat
Eine Spalte ohne C, die erkannt und nie dem Fachbereich vorgelegt wurde, bleibt ein Mangel des Modells. Jeder Befund trägt eine verantwortliche Person und eine Frist.
KI-Überlegungen
Ein Sprachmodell füllt aus den Texten der Anwendungsfälle und einer Liste der Entitäten in wenigen Sekunden ein erstes Raster. Es füllt die Lücken mit plausiblen Buchstaben. Die Lücken sind aber das Ergebnis der Technik.
Die Analystin verlangt vom Modell zu jedem Buchstaben den Schritt des Szenarios, der ihn begründet. Sie verwirft jeden Buchstaben ohne zitierten Schritt. Das Modell prüft auch ein von Hand erstelltes Raster: Es listet die auffälligen Spalten auf und formuliert zu jeder die Frage an den Fachbereich. Eine Tabellenkalkulation zählt die Buchstaben. Das Modell formuliert die Fragen.
Bei einem bestehenden System liest ein Sprachmodell die Stored Procedures und den Datenzugriffscode. Es extrahiert die SQL-Operationen je Tabelle und schlägt ein Raster des Systems im Ist-Zustand vor. Die Analystin vergleicht dieses Raster mit dem Raster der Anforderungen. Sie sieht, was der Code ohne Anforderung tut und was die Anforderungen ohne Code verlangen. Sie validiert die Zuordnung der technischen Tabellen und Kurznamen zu den fachlichen Entitäten.
Stored Procedures, Texte der Anwendungsfälle und Datenmodell verlassen die Organisation, wenn die Analystin sie an ein externes Modell schickt. Die echten Daten, die in den Texten stehen, gehen mit. Die Analystin nutzt eine von der Organisation freigegebene Instanz oder entfernt zuerst die echten Daten aus den Texten.
Beispiele
Eine Gemeinde spezifiziert ihr Modul für die Hundesteuer. Das Raster kreuzt ihre Anwendungsfälle mit den Entitäten ihres Datenmodells. Die Spalte Tarif trägt nur ein R.
| Anwendungsfall | Halter | Hund | Tarif | Rechnung |
|---|---|---|---|---|
| Hund anmelden | C R | C | ||
| Halterwechsel melden | C R | U | ||
| Tod oder Wegzug eines Hundes melden | R | U | ||
| Fehlerhafte Anmeldung stornieren | D | |||
| Jährliche Hundesteuer fakturieren | R | R | R | C |
| Zahlung verbuchen | R U |
Kein Anwendungsfall erstellt oder ändert einen Tarif. Die Fakturierung liest trotzdem jedes Jahr einen Betrag. Der Befund stellt der Finanzverwaltung eine Frage: Wer erfasst den Jahrestarif, den der Gemeinderat beschliesst? Die Antwort fügt dem Modell den Anwendungsfall "Jahrestarif festlegen" hinzu (C, U auf Tarif). Die Finanzverwaltung ist sein Akteur.
Auch die übrigen Spalten lösen Prüfungen aus. Die Spalte Halter trägt zwei C und kein U. Der Fachbereich bestimmt für sie die massgebende Quelle und entscheidet, welcher Anwendungsfall einen Adresswechsel erfasst. Nur die Spalte Hund trägt ein D. Der Fachbereich legt die Aufbewahrungsdauer für Halter, Tarif und Rechnung fest. Die Analystin trägt jeden dieser Befunde in die Liste ein.
Visualisierungen
Das Ergebnis bleibt eine sortier- und filterbare Tabelle. Die Prozesse folgen dem Lebenszyklus der Ressource. Die Buchstaben einer Zelle folgen der Reihenfolge C, R, U, D. Eine bedingte Formatierung hebt die auffälligen Spalten hervor. Die Prüferin sieht die Befunde, ohne Buchstaben zu zählen. Die Liste der Befunde begleitet das Raster und verweist mit dem Namen auf jede Spalte.
Kosten
| Dimension | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Mittel | Anwendungsfälle und Datenmodell müssen im gleichen Detaillierungsgrad vorliegen. Fehlt eines davon, erstellt die Analystin es zuerst. |
| Durchführung | Gering | Das Ausfüllen folgt den Schritten der Szenarien. Ein Raster von rund zwanzig Anwendungsfällen mal fünfzehn Entitäten braucht einen halben Tag. |
| Dokumentation | Mittel | Das Raster folgt jeder Änderung der beiden Modelle. Von Hand gepflegt, weicht es bei jeder Änderung ab, die niemand nachträgt. |
Werkzeuge
Für ein Raster von rund dreissig Zeilen genügt eine Tabellenkalkulation. Eine Formel pro Spalte zählt jeden Buchstaben. Die bedingte Formatierung färbt die auffälligen Spalten ein. Die Tabellenkalkulation folgt den Modellen nicht: Die Analystin trägt jede Änderung eines Anwendungsfalls oder einer Entität von Hand nach.
Modellierungswerkzeuge erzeugen das Raster als Sicht, die den Änderungen des Modells folgt. Sparx Enterprise Architect zeigt in seiner Beziehungsmatrix die Verbindungen zwischen Anwendungsfällen und Klassen. Die Analystin trägt dort die Buchstaben ein. Visual Paradigm erzeugt aus den modellierten Prozessen und Entitäten eine CRUD-Tabelle. Diese Sichten eignen sich, sobald die Modelle im Werkzeug leben.
Für ein bestehendes System extrahieren Werkzeuge der statischen Codeanalyse und Datenkataloge die Operationen je Tabelle. Sie liefern das Raster des Systems, wie es läuft.
Quellen
- IBM, Business Systems Planning: Information Systems Planning Guide, GE20-0527-2, 2. Auflage, 1978: in Kapitel 7 das Raster der Datenklassen gegenüber den Prozessen mit den Markierungen C und U; in Kapitel 11 die diagonale Gruppierung, die die Teilsysteme und die Datenflüsse zwischen ihnen abgrenzt.
- Politano, A. L., Salvaging Information Engineering Techniques in the Data Warehouse Environment, Informing Science 4(2), 2001, S. 35-43: die CRUD-Matrix als Ergebnis des strategischen Plans des Information Engineering, ihre Prüfungen (Mehrfacherstellung, Verhältnis von Erstellen zu Lesen, Clustering) und ihre Verwendung in der Auswirkungsanalyse und der Schätzung.
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, Glossar, Eintrag create, read, update, and delete matrix (CRUD matrix): die Definition über Benutzerrollen und die Erweiterung auf Prozesse.
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.39 Roles and Permissions Matrix: der Verweis auf eine CRUD-Matrix für die Rollen und Verantwortlichkeiten von IT-Systemen.
- Schweizerische Eidgenossenschaft, Bundesgesetz über den Datenschutz (DSG), SR 235.1, Art. 6 Abs. 3 und 4: die Beschaffung von Personendaten nur zu bestimmten und erkennbaren Zwecken, danach ihre Vernichtung oder Anonymisierung, sobald sie nicht mehr nötig sind.

