Das fachliche Datenmodell im Lastenheft

Das Datenmodell ist ein Begriff, der immer wieder im Requirements Engineering und in der Design- und Umsetzungsphase eines Softwareprojekts verwendet wird. Aber was ist eigentlich ein Datenmodell und wo liegt der Unterschied zum fachlichen Datenmodell? Und wieso sollte man bei Bedarf das fachliche Datenmodell in das Lastenheft mit einbeziehen? Diesen Fragen stellen wir uns und beantworten im Folgenden.

 

Das Datenmodell beschreibt eine Abbildung der gesamten Datenstruktur in einem System. Das sind in erster Linie Datenbanken, darin enthaltene Tabellen und deren Beziehungen sowie die jeweiligen Attribute. Seit Big Data können auch weitere Strukturen in einem Datenmodell abgebildet werden, wie zum Beispiel bei einer Graphendatenbank, in der keine Tabellen an sich existieren. Aber auch hier kann man eine technische Beschreibung liefern, indem die definierten Arten von Objekten und deren Abhängigkeiten erläutert werden. Insgesamt gilt dabei für jedes Datenmodell: technologie- und programmorientiert. Im Datenmodell fließt die verwendete Technologie und die im Endeffekt zu realisierende Struktur ein.

Das fachliche Datenmodell hingegen ist nicht technologieorientiert. Der Fokus liegt auf den sich in einem Datenmodell befindlichen fachlichen Informationen. So werden wichtige Objekte, deren Beziehungen zueinander und relevante Attribute definiert, die zum fachlichen Verständnis beitragen. Mechanismen zur historischen Erfassung oder zur Abbildung von Kardinalitäten werden nicht explizit erfasst, da es sich dabei um technische Anforderungen hinsichtlich der Realisierung handelt. Der Unterschied zwischen dem Datenmodell und dem fachlichen Datenmodell kann grob als der Abstraktionsgrad gesehen werden. Das fachliche Datenmodell kann dabei in einer tabellarischen Form als Auflistung aller Objekte und deren Attribute samt weiterer Eigenschaften (z.B. Typ, Lese- und Schreibrechte, erlaubte Werte, …) oder in Form eines Entity-Relationship-Diagramms abgebildet werden. Häufig werden auch beide Darstellungsformen miteinander kombiniert, um von allen Vorteilen zu profitieren.

Das fachliche Datenmodell als Ergänzung zum Lastenheft oder anderen Anforderungsdokumenten bringt einige erhebliche Vorteile mit sich. Mit steigender Komplexität und durch die vielen Stakeholder entstehen unter anderem mehrdeutige Anforderungen, Inkonsistenzen, verschiedene Begrifflichkeiten und ein hoher Interpretationsspielraum. Um dem vorzubeugen ermöglicht das fachliche Datenmodell eine umfangreichere Erfassung der Anforderungen durch die Anreicherung von fachlichen Informationen. Zudem wird eine zentrale Stelle für wichtige Objekte und Attribute geboten, auf die in allen Anforderungen verwiesen werden kann. Dadurch wird Inkonsistenzen und Fehlern vorgebeugt. Zudem kann durch die Einführung eines fachlichen Datenmodells im Rahmen des Anforderungsmanagements ein gemeinsames Verständnis der Objekte und Beziehungen generiert werden, was auch dazu führt, dass implizites Wissen der Stakeholder expliziert und abgestimmt wird. Diese frühe Abstimmung wichtiger Attribute und Inhalte führt zu einer Kostensenkung, da bereits in einer frühen Phase des Projekts Fehler erkannt und bereinigt werden können.

Die Entscheidung über die Verwendung des fachlichen Datenmodells als Ergänzung von Anforderungsdokumenten sollte für jedes einzelne Projekt gesondert getroffen werden. Je nach Charakteristik, Komplexität und Größe des Projekts muss es nicht notwendig sein, ein fachliches Datenmodell zu führen. In jedem Fall ist es jedoch nicht überflüssig oder falsch, ein fachliches Datenmodell zu entwerfen. Spätestens beim technischen Entwurf und der Implementierung des Systems müssen sich die Stakeholder mit den Objekten und Attributen beschäftigen und den bereits erhobenen Systemkontext neu durchleuchten. So gesehen spart der frühe Entwurf des fachlichen Datenmodells später in jedem Fall Zeit und Kosten.

Zusammenfassend lässt sich festhalten, dass der Verwendung eines fachlichen Datenmodells im Requirements Engineering ausschließlich Vorteile bringt. Zwar entstehen kurzzeitig höhere Kosten, da eine Erhebung von Objekten, deren Beziehungen und Attribute einen zeitlichen Aufwand darstellt, diese Kosten relativieren sich jedoch spätestens in der Umsetzungsphase, wenn das technische Datenmodell konzeptioniert wird und der fachliche Input dafür bereits vorhanden ist. Die Darstellung des fachlichen Datenmodells ist nicht standardisiert und soll sich am Charakter des Projekts und der Anforderungsdokumente orientieren. Es empfiehlt sich auch die Darstellung des fachlichen Datenmodells sowohl visuell als auch in tabellarischer Form, um alle Vorteile auszuschöpfen.