Was ist die Modellierung von Informationssystemen ?

Sind die Anforderungen bekannt, ist eine Lösung ausgewählt und ist der Start zur Projektdurchführung gegeben, müssen nun die zu erstellenden Informationssysteme so beschrieben werden, dass die Lösung umgesetzt werden kann. 

Was ist ein Lasten- und Pflichtenheft?

Ein Lastenheft

• Beschreibt die „Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers“ (Definition nach DIN 69905)
• Soll vom Auftraggeber formuliert werden
• Dient als Grundlage zur Einholung von Angeboten oder als Kalkulationsgrundlage
• Wird auch gelegentlich als Leistungsverzeichnis (LV) bezeichnet

Ein Lastenheft soll im Wesentlichen folgende Inhalte umfassen:

• Die Spezifikation des zu erstellenden Produkts (die „Last“)
• Die Anforderungen an das Produkt bei seiner Verwendung (z.B. Rechner- und Betriebssystemumgebung)
• Rahmenbedingungen für das Produkt und für die Leistungserbringung (z.B. einzuhaltende Normen)
• Vertragliche Konditionen (z.B. Erbringen von Teilleistungen, Gewährleistungsanforderungen, Risikomanagement usw.)
• Anforderungen an den Auftragnehmer (z.B. Zertifizierung nach ISO 9001)
• Anforderungen an das Projektmanagement des Auftragnehmers (z.B. Projektdokumentation, Qualitätsmanagement)

Ein Lastenheft beschreibt somit das WAS in einer möglichst umfassenden Form, allerdings ohne auf Details der Implementierung einzugehen. 

Ein Pflichtenheft

• Bildet die Grundlage für die vertraglich festgehaltenen und bindenden Leistungen eines Auftragnehmers
• Beinhaltet „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben“ (Definition nach DIN 69905)
• Beschreibt somit die Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes und ist daher die organisatorische und/oder technische Vorgabe zur Realisierung eines Projekts
• Wird gelegentlich auch als Fachfeinkonzept bezeichnet

Im Gegensatz zum Lastenheft sind die Inhalte es Pflichtenhefts daher präzise, vollständig und nachvollziehbar dokumentiert sowie mit technischen Festlegungen verknüpft, welche z.B. die Betriebs- und Wartungsumgebung festlegen. Das Pflichtenheft beschreibt somit das WIE einer Umsetzung.

Auch wenn die Begriffe „Auftraggeber“ und „Auftragnehmer“ eher aus dem Kontext einer Kunden-Lieferantenbeziehung kommen, wo eine Organisation mit dem Lastenheft beschreibt, WAS gewünscht/benötigt wird und daraufhin ein externer Lieferant ein Angebot legt, einen Zuschlag erhält und dann mit dem Pflichtenheft das WIE präzisiert, gelten diese Begriffe auch innerhalb eines unternehmensinternen Kontexts. 

Hier ist der Auftraggeber jene Person oder Abteilung, die einen Bedarf hat und diesen möglichst präzise (wenn auch noch nicht detailliert) in einem Lastenheft festlegt. Der Auftragnehmer – eine interne IT-Abteilung beispielsweise – wird daraufhin die Umsetzung in einem Pflichtenheft dokumentieren und mit dem Auftraggeber abstimmen. 

Besonders sei an dieser Stelle darauf hingewiesen, dass mit dem Pflichtenheft eine vertraglich bindende Zusage über die Ausführung einer Leistung getroffen wird (siehe oben). Da das Pflichtenheft auch nur das präzisieren und festlegen kann, was im Lastenheft als Anforderung formuliert ist, ist auf die Qualität beider Dokumente große Sorgfalt zu legen.

Wie können Anforderungen beschrieben werden?

Somit stellt sich die Frage, wie Anforderungen (im Lastenheft) formuliert sein müssen, damit diese den Bedarf des Auftraggebers möglichst präzise, vollständig und zweifelsfrei dokumentieren. Hierzu wurden in den letzten Jahrzehnten eine Reihe von Werkzeugen und Techniken entwickelt und teilweise auch normativ festgehalten.

Welche Qualitätskriterien für Anforderungen gibt es?

Eindeutigkeit

Lässt jede Anforderung nur eine einzige Interpretation zu? 

Ist Gleiches immer gleich benannt?

 Verständlichkeit

Ist die Anforderung für alle Beteiligten verständlich?
Ist die Ausdrucksweise präzise? 
Sind spezielle Begriffe im Glossar enthalten?

 Angemessenheit 

Entsprechen die festgelegten Funktionen den Wünschen und Bedürfnissen der Benutzer sowie den Business Requirements? 

Sind die Anforderungen wirtschaftlich umsetzbar und realisierbar?

Testbarkeit

Ist die Erfüllung der Anforderungen überprüfbar?
Wie kann die Anforderung getestet werden?

Widerspruchsfreiheit, Abhängigkeit

Gibt es Konflikte zwischen den Anforderungen? 
Kann die Anforderung ohne Auswirkung auf andere Anforderungen geändert werden?

Wie sieht eine Dokumentation von Anforderungen aus?

Gemäß dem Lehrplan zum Foundation Level – IREB Certified Professional for Requirements Engineering (IREB International Requirements Engineering Board e.V., 2011) gilt als Dokumentationstechnik jegliche Art der mehr oder weniger formalen Darstellung von Anforderungen, angefangen von der Beschreibung in Prosaform bis hin zu Diagrammen mit einer formalen Semantik. 

Anforderungsdokumente umfassen – unter anderem – funktionale Anforderungen, welche üblicherweise die folgenden drei verschiedenen Perspektiven eines Systems repräsentieren:

• Eine Strukturperspektive
• Eine Verhaltensperspektive und
• Eine Funktionsperspektive

Alle drei Perspektiven lassen sich mittels natürlichsprachiger Anforderungen dokumentieren, während konzeptuelle Modelltypen auf eine dieser Perspektiven spezialisiert sind. Effektiv einsetzbare Formen der Dokumentation sind

• Natürlichsprachige Anforderungsdokumentation
• Konzeptuelle Anforderungsmodelle wie z.B. Use-Case-Diagramme
• Mischformen von Anforderungsdokumentation

Natürlichsprachig formulierte Anforderungen haben unter anderem den Vorteil der Einfachheit, indem Anforderungen so dokumentiert werden können „wie diese formuliert werden“. Dem steht der erhebliche Nachteil gegenüber, dass Sprache meist nicht eindeutig genug ist, um den Qualitätskriterien für Anforderungen zu genügen. Möglichkeiten, dem zu begegnen sind unter anderem die Verwendung von Satzschablonen, die Verwendung von kurzen Sätzen und Absätzen sowie die Formulierung von nur einer Anforderung pro Satz.

Modellbasiert dokumentierte Anforderungen haben den Vorteil, dass oft mit einem Bild „mehr als mit 1000 Worten“ gesagt wird. Voraussetzung ist allerdings, dass alle beteiligten Personen mit der Symbolik und der Semantik solcher grafischen Darstellungen vertraut sind und diese gleichermaßen verstehen. Ferner sind oft spezielle Werkzeuge notwendig, was mit Investitionen und Einschulungsaufwand verbunden ist.

Aber auch Bilder alleine genügen meist nicht, um Anforderungen zu beschreiben. In der Praxis werden daher Mischformen verwendet. Beispielsweise werden Anforderungen auf hoher Abstraktionsebene sowie zur Darstellung bestimmter Details grafisch modelliert und zusätzlich textuell nach einem vorgegebenen Schema natürlichsprachig beschrieben. Diese Vorgangsweise hat den Vorteil, dass große Teile der Anforderungen übersichtsweise grafisch dargestellt und erfasst werden können und dass die natürlichsprachige Beschreibung bei Bedarf zusätzliche Informationen bereitstellt.

Wie auch immer Anforderungen letzten Endes beschrieben werden benötigt die Dokumentation von Anforderungen meist folgende Minimalstruktur:

• ID des Requirements
• Formale Methoden (z.B. UML) und deren Elemente
• Status des Requirements
• Herkunft, Begründung, Autor
• Typ (FURPS+ oder andere Klassifikation, siehe Klassifikation von Anforderungen)
• Beschreibung, Beschreibungstiefe, Alternativszenarien
• Vorbedingungen, Nachbedingungen
• Priorität, Risiken
• Testkriterien, Testszenarien
• Änderungshistorie

Anforderungen müssen also 

• eindeutig identifizierbar sein
• entsprechend beschrieben sein
• einen Status haben (z.B. „Neu“, „zur Prüfung“, „Freigegeben“)
• eine Quellangabe und den Autor beinhalten sowie eine Begründung angeben, warum und wozu diese Anforderung benötigt wird
• eine Klassifikation aufweisen
• angemessen ausführlich beschrieben werden samt möglicher Alternativszenarien
• Vorbedingungen (unter welchen Umständen wird eine Funktion ausgeführt) und Nachbedingungen (was liegt nach Ausführung einer Funktion vor) beinhalten

usw. 

Um eine einheitliche Beschreibungstiefe und einen einheitlichen Stil zu gewährleisten, bieten sich sogenannte Anforderungsschablonen an, beispielsweise gemäß folgendem Auszug aus einer Schablone:

Wie werden Anforderungen klassifiziert?

Anforderungen beschreiben nicht nur Funktionen eines Systems, sondern beinhalten eine Vielzahl von Qualitätsanforderungen und Randbedingungen; dies wird meist unter dem Begriff nicht-funktionale Anforderungen zusammengefasst.

Anforderungen können auf verschiedene Arten klassifiziert werden. Ein Auszug aus einem Schema für nicht-funktionale Anforderungen, welches beispielsweise auch kulturelle und politische Aspekte berücksichtigt, ist jenes nach (Robertson, 2012):

10. Look and Feel Requirements
10a. Appearance Requirements
10b. Style Requirements
11. Usability and Humanity Requirements
11a. Ease of Use Requirements
11b. Personalization and Internationalization Requirements
11c. Learning Requirements
11d. Understandability and Politeness Requirements
11e. Accessibility Requirements

12. Performance Requirements
12a. Speed and Latency Requirements
12b. Safety-Critical Requirements
12c. Precision or Accuracy Requirements
12d. Reliability and Availability Requirements
12e. Robustness or Fault-Tolerance Requirements
12f. Capacity Requirements
12g. Scalability or Extensibility Requirements

13. Operational and Environmental Requirements
13a. Expected Physical Environment
13b. Requirements for Interfacing with Adjacent Systems
13c. Productization Requirements
13d. Release Requirements

14. Maintainability and Support Requirements
14a. Maintenance Requirements
14b. Supportability Requirements
14c. Adaptability Requirements

15. Security Requirements
15a. Access Requirements
15b. Integrity Requirements
15c. Privacy Requirements
15d. Audit Requirements
15e. Immunity Requirements

16. Cultural and Political Requirements
16a. Cultural Requirements
16b. Political Requirements

17. Legal Requirements
17a. Compliance Requirements17b. Standards Requirements

Eine andere mögliche und übliche Klassifikation von Anforderungen ist jene nach FURPS+, wobei das „F“ schon die funktionalen Anforderungen umfasst. Die Zeichen von FURPS+ stehen im Einzelnen für

1. Functionality (Funktionalität)
2. Usability (Benutzbarkeit)
3. Reliability (Zuverlässigkeit)
4. Performance (Effizienz) und/oder Portability (Übertragbarkeit/Wartbarkeit)
5. Supportability (Änderbarkeit)
6. + Sonstige Anforderungen, die nicht in obige Kategorien passen

Klassifikationen von Anforderungen finden sich auch in etlichen Normen, hier beispielsweise ein Auszug aus der früheren ISO/IEC 9126-1:2001:

Die nicht-funktionalen Anforderungen sind mindestens so wichtig wie die funktionalen Anforderungen, werden aber in der Praxis oft unterschätzt. Bietet beispielsweise ein System die gewünschte Funktionalität in bestmöglicher Form, dauert jedoch jede durchgeführte Interaktion mit dem System mehrere Sekunden, dann wird das System keine Akzeptanz finden, weil vielleicht das Zeitverhalten nicht korrekt berücksichtigt wurde.

Sichten und Perspektiven

Welche drei verschiedenen Perspektiven eines Systems gibt es?

Nach (Pohl & Rupp, 2011) umfassen (wie oben ausgeführt) Anforderungsdokumente – unter anderem – funktionale Anforderungen, welche üblicherweise die folgenden drei verschiedenen Perspektiven eines Systems repräsentieren:

• Eine Strukturperspektive
• Eine Verhaltensperspektive und
• Eine Funktionsperspektive

Alle drei Perspektiven lassen sich mittels natürlichsprachiger Anforderungen dokumentieren (wobei die Perspektiven dann meist vermischt werden), während konzeptuelle Modelltypen auf eine dieser Perspektiven spezialisiert sind, worauf hier näher eingegangen wird.

In der Strukturperspektive werden beispielsweise die Struktur von Ein- und Ausgabedaten sowie die statisch-strukturellen Aspekte von Nutzungs- und Abhängigkeitsbeziehungen eines Systems dokumentiert. Es wird also eine statisch-strukturelle Sicht auf die Anforderungen an das System eingenommen. Typische Diagramme hierfür sind das ER-Diagramm (Entity Relationship-Diagramm) und UML-Klassendiagramme.

In der Verhaltensperspektive werden das System und dessen Einbettung in den Systemkontext zustandsorientiert dokumentiert, indem beispielsweise die Reaktion des Systems auf Ereignisse dargestellt wird. Typische Diagramme hierfür sind UML-Zustandsdiagramme.

In der Funktionsperspektive wird dargestellt, welche Informationen aus dem Systemkontext durch das System bzw. durch dessen Funktionen verarbeitet werden und welche Daten in das und aus dem System fließen. Geeignete Diagramme sind Datenfluss-Diagramme oder UML-Aktivitätsdiagramme.

Die in den jeweiligen Modellen der verschiedenen Perspektiven abgebildeten Inhalte finden sich zum Teil auch in anderen Perspektiven wieder. So können beispielsweise Daten, deren statische Struktur in UML-Klassendiagrammen definiert ist, auch in der Funktionsperspektive vorkommen, da sie z.B. im Objektfluss die Ein- und Ausgabedaten für Aktionen in den Aktivitätsdiagrammen darstellen. In diesem Sinne sind diese drei Perspektiven natürlich stark voneinander abhängig, weswegen auch nicht erst eine Perspektive dokumentiert werden kann und dann die anderen, sondern die Dokumentation parallel erfolgen muss.

Was ist die Datensicht und Funktionssicht?

Aus (Scheer, 1997): Eine Funktion kennzeichnet jeweils einen Vorgang und beschreibt das „Was“. Sie erzeugt oder verändert Objekte. Eine komplexe Funktion kann in Teilfunktionen zerlegt werden, um deren Komplexität zu reduzieren.

Funktionen werden z.B. durch Hierarchiediagramme oder Funktionsbäume konkretisiert. Hierarchiediagramme sind praktisch selbsterklärend, wie das folgende Beispiel einer Auftrags-abwicklung zeigt:

Die Funktionen werden dabei durch gerundete Rechtecke dargestellt. Funktionen können über mehrere Hierarchieebenen zerlegt werden, wie es in der Abbildung die Teilfunktionen Auftragsbearbeitung und Reservierung zeigen. Der Zerlegungsprozess endet, wenn Funktionen erreicht werden, die in einem Arbeitsablauf bearbeitet werden, also betriebswirtschaftlich nicht mehr sinnvoll zerlegt werden sollen. Diese werden als Elementarfunktionen bezeichnet.

Häufig bestehen keine eindeutigen Kriterien für eine Funktionsgliederung. Mögliche Gliederungs-kriterien sind die Zerlegung von Teilfunktionen nach ihrem groben zeitlichen Ablauf, der Bearbeitung gleicher Informationsobjekte oder nach gleichen Verrichtungen.

Zur detaillierten Beschreibung der Funktionsausführung (das „Wie“), eignen sich beispielsweise Struktogramme nach Nassi/Shneiderman. Diese werden zwar hauptsächlich bei der Erarbeitung eines DV-Konzepts eingesetzt, dienen aber auch zur detaillierten Beschreibung betriebswirtschaftlicher Algorithmen im Rahmen des Fachkonzepts.

Beim Fachentwurf der Funktionen ist auch festzulegen, wie der Benutzer auf deren Ablauf einwirken kann. Als grundsätzliche Bearbeitungsformen können die automatische Verarbeitung ohne Eingriff des Benutzers und die interaktive Verarbeitung unterschieden werden.

Bei der Bearbeitung ohne Benutzereingriff werden häufig gleichartige Vorgänge gesammelt und in einem geschlossenen Durchlauf verarbeitet (Batchverarbeitung). Batch-orientierte Planungsläufe werden häufig zu vorher festgelegten Zeitpunkten (z.B. am Ende einer Woche oder zu Beginn eines Monats) für den anstehenden Planungszeitraum durchgeführt.

Die Beschreibung des Fachkonzepts der Datensicht ist methodisch besonders anspruchsvoll. Während bei der Funktionssicht lediglich ein Begriff, nämlich die Funktion, benötigt wird, werden innerhalb der Datensicht vielfältige Begriffe wie Entitytypen, Beziehungstypen, Attribute und Domänen usw. verwendet.

Innerhalb der Funktionsbeschreibung werden lediglich zwei Arten von Beziehungen zwischen Funktionen – die hierarchische Unterordnung sowie die Vorgänger-/Nachfolgerbeziehung, benötigt. Zwischen Datenobjekten können jedoch vielfältige und wesentlich schwieriger zu klassifizierende Beziehungen bestehen.

Es hat sich herausgestellt, dass gerade das Fachkonzept der Daten für die Gestaltung eines Informationssystems immer wichtiger wird. Je leichter durch den Einsatz höherer Programmiersprachen Funktionszusätze an bestehende Programmsysteme erstellt werden können, umso wichtiger wird es, diese Funktionen auch mit den richtigen Datenstrukturen zu versorgen. Hinzu kommt, dass Datenstrukturen nur mit erheblichem Aufwand geändert werden können.

Diese Faktoren führen dazu, dem Fachkonzept der Datensicht größere Aufmerksamkeit zu widmen. Als am weitesten verbreitete Entwurfsmethode gilt das Entity-Relationship-Modell von Chen, auf welches im Studienbrief „Datenbanksysteme“ näher eingegangen wird.