Teil 3: Tools – Fluch oder Segen?

Nachdem ich in unserer letzten Folge „Malen oder Schreiben“ ein wenig über die Vor- und Nachteile der jeweiligen Notationsarten sinniert und ein Plädoyer für die gleichzeitige Verwendung von natürlicher Sprache und Grafiken gehalten habe, stellt sich nun die naheliegende Frage: Wie dokumentiert man das alles?

Ab hier fängt es an schwierig zu werden, denn so sehr Tools einem das Leben erleichtern können, so sehr können sie uns auch einschränken. Auf der einen Seite haben wir die Programme, die uns helfen Anforderungen zu verwalten (RM-Tools) und auf der anderen Seite Programme für die Modellierung (CASE-Tools). Obwohl es von beiden Seiten Ansätze gibt die jeweils andere Disziplin zu integrieren (Modellierungs-Funktionen in RM-Tools oder Anforderungsverwaltung in CASE-Tools), gibt es bis dato noch kein Tool, dass beide Notationsarten gleichermaßen gut und zufriedenstellend unterstützt.

Diese Tatsache hat dazu geführt, dass Text und Modelle in den meisten Projekten in friedlicher, wenn auch ineffizienter Koexistenz leben, oder sich das Projektteam aus Gründen der Kosten und der Einfachheit für eine Notationsart entscheidet.

Ich könnte es mir jetzt natürlich leicht machen und eine „Was wäre wenn“ Geschichte erzählen, sprich die ideale Tool-Lösung skizzieren. Doch das würde wenig helfen (außer ein Toolhersteller liest diesen Eintrag und setzt es um). Statt dessen möchte ich zeigen, wie wir im täglichen Projekt-Leben mit der Situation umgehen und die Problematik bestmöglich bewältigen.

Davor müssen wir jedoch etwas genauer betrachten, womit wir es zu tun haben und welche Voraussetzungen wir für notwendig erachten.

Modellierungs-Tools

Malen ist nicht gleich malen! Es gibt große Unterschiede zwischen kreativen, hübschen und bunten Freihandbildern aus einem Zeichenprogramm wie Powerpoint und formalen Modellen in einem speziellen Modellierungs-Tool wie z. B. Enterprise Architect. Folgende Aspekte bestimmen unter anderem die Qualität eines Modelles:

1. Formalität: Bilder lassen viel Interpretationsspielraum offen, gerade wenn sie keiner einheitlichen, standardisierter Notation wie z. B. der UML folgen sondern Eigenkreationen sind – denen es oft genug an Durchgängigkeit, Intuitivität und Konsistenz mangelt.

Tipp: Je mehr Personen mit dem Modell arbeiten müssen (lesend und/oder schreibend) und je langlebiger die Modelle sein sollen, desto mehr Formalheit ist ratenswert.

2. Das Repository: Etwas, das spezielle Modellierungs-Tools von einfachen Grafik-Tools grundlegend unterscheidet, ist das sogenannte Repository. Dieses Repository ist ein Container, in dem alle Modellelemente und deren Verbindungen untereinander gespeichert werden. Jedes Element existiert nur ein einziges Mal, egal in wievielen Diagrammen es verwendet wird. Es besitzt eine eindeutige ID und alle Informationen bezüglich dieses Elementes sind an einer zentralen Stelle gesammelt. Sobald man das Element in einem Diagramm umbenennt, wird diese Änderungen in allen Diagrammen wirksam und sichert so die Konsistenz des Modells – dieser Automatismus birgt natürlich auch Gefahren, besonders wenn mehrere Modellierer am Werk sind!

Tipp: Je komplexer ein Modell ist und je mehr Personen an diesem arbeiten, desto eher rentiert sich die Investition in ein Modellierungs-Tool.

RM-Tools

Auch bei natürlichsprachigen Anforderungen gibt es mehrere Möglichkeiten der Tool-Unterstützung. Diese variieren von Textverarbeitungsprogrammen über Tabellenkalkulationsprogrammen, Wikis und Mind-Maps bis hin zu speziellen Anforderungsmanagement-Tools. Somit reicht auch der mögliche Inhalt von romantischer Prosa bis hin zu formalen Anforderungen nach einem Template formuliert und mit Attributen versehen. Es gibt einige Kriterien für die Qualität von Anforderungen und Anforderungsdokumenten, für unser Thema sind aber vor allem folgende Voraussetzungen ungemein hilfreich:

1. Identifizierbarkeit: Anforderungsdokument, die als 100-seitige Erlebniserzählung daher kommen, sind zwar vielleicht nett zu lesen, aber nicht praktikabel. Einzelne Anforderungen können nicht referenziert werden. Für den Zweck der weiteren Verwendung im Projekt (Traceability, Tests, Änderungen) sind atomare Anforderungen mit einer eindeutigen IDs unablässlich.

Tipp: Hierin liegt ein großer Vorteil spezieller RM-Tools, da sie einem diese Arbeit abnehmen, indem sie die IDs automatisch und eindeutig vergeben.

2. Attributierbarkeit: Die Möglichkeit einzelne Anforderungen durch Meta-Informationen zu ergänzen besteht natürlich in jedem Tool, ein RM-Tool ermöglicht es jedoch diese Zusatzinformationen nicht einfach in den Text der Anforderung zu integrieren – was jeder Autor zweifelsohne unterschiedlich machen würde – sondern in sogenannten Attributen zu verwalten. Für jedes Attribut kann festgelegt werden, ob es optional oder obligatorisch ist und welchen Wert es haben darf.

Tipp: Wer viele Anforderungen aus unterschiedlichen Anforderungsquellen hat und die Anforderungsdokumentation nicht nur als Wegwerf-Produkt sondern über die gesamte Lebensspanne des Systems verwendet, kommt um das Thema Attribute m. E. nicht herum.

Zum Abschluss möchte ich noch einmal betonen, dass jedes Projekt unterschiedlich ist. Es gibt nicht DEN idealen Lösungsweg und DAS ideale Tool für alle! Die Dokumentation muss vor allem eines sein: angemessen. Je größer das Projekt, je mehr Informationen verwaltet werden, je mehr Personen involviert sind und je länger das Projekt dauert, desto mehr Aufwand fließt in die Kommunikation und die Dokumentation des Wissens und desto größer wird der Bedarf Nachvollziehbarkeit und Überblick durch spezielle Tools und Methoden zu ermöglichen.

Wir werden uns in den nächsten Folgen die beiden möglichen Verbindungen von natürlichsprachlichen Anforderungen und Modellen ansehen (siehe Illustration):

• Verbindung zwischen natürlichsprachlichen Anforderungen und dem Anforderungsmodell in der Analyse
• Verbindung zwischen Anforderungen (sowohl natürlichsprachlich als auch grafisch) und dem Architektur-Modell.

Wie immer sind Sie herzlich eingeladen uns Ihre Erfahrungen und Anmerkungen zu diesem Thema mitzuteilen. Wir freuen uns über jeden sachdienlichen Hinweis!

Falls Sie Interesse an weitere Informationen rund um die hier angesprochenen Themen haben, schreiben Sie uns einfach eine Mail an heureka@sophist.de.