Die Modulspezifikation

Ein wichtiger Teil jeder Architektur ist die Gestaltung der fachlich, funktionalen Spezifikationen und deren Übergang, Nutzung und Einbindung in die Planung, Entwicklung und Wartung. Gleichzeitig jedoch ist gerade diese Gestaltung auch sehr individuell.

ISA erfindet hier das Rad nicht neu und definiert auch kein starres Spezifikationsmodell. Dennoch bietet ISA mit seinem eindeutigen Modulkonzept einen zentralen Angelpunkt, an dem jedes individuelle Spezifikationsverfahren eingehängt werden kann. Ziel dabei ist – einen Single Point of Truth – in Form einer zentralen Modulanforderungsliste anzubieten (siehe auch Architektur).

Die Modulanforderungsliste ist eine einfache, allgemeinverständliche Liste1 von fachlich/funktionalen Anforderungen an ein Modul. Sie ist nicht die konkrete technische Spezifikation und sie ist auch nicht die detaillierte fachliche Beschreibung. Die Anforderungsliste beschreibt allgemein nur das Was ein Modul leisten soll – und dient als zentraler Drehpunkt für das Management, die Fachlichkeit und die Technik. (Beispiel: Login Modul –  isa.wb.Login-1.x.xls).

Die inhaltliche und technische Spezifikation eines Moduls erfolgt getrennt in einer individuellen Modulspezifikation (z.B. Dokument und/oder Modell etc.), die wiederum auf die Anforderungsliste verweist und diese ggf. auf weitere benötigte reine Fachspezifikationen. Die Modul- und die Fachspezifikationen definieren das Wie dessen, was benötigt wird. Zum einen bzgl. des Wie der technischen Umsetzung und zum anderen bzgl. des Wie des fachlichen Inhalts – beides klar getrennt – aber verlinkt über die Anforderungsliste (Beispiel: Login Modul - isa.wb.Login-1.x.doc).

Specification

Mit diesem Konzept ergibt sich zum einen eine klare Trennung zwischen Fachlichkeit und Technik und zum anderen entsteht eine gerichtete Verlinkung und Abbildung, die es allen Beteiligten ermöglicht hohe Redundanzfreiheit, einfache Nachvollziehbarkeit und unabhängiges Arbeiten zu gewährleisten2.

Darüber hinaus ist das Konzept sowohl dafür geeignet schnell, einfach und flexibel in agilen Vorgehen eingesetzt zu werden – als auch dafür – Produkte oder gewerkliche Dienstleistungen  im Ganzen, kalkulierbar und abnahmefähig zu definieren3.

_______________________
1: Sowohl ein Manager, als auch ein Fachspezialist, als auch ein Architekt, Desiger, Entwickler oder Tester kann eine Anforderung wie z.B. Modul: isa.wb.Login-1.x/Anforderung-Anmeldung-1:

  • “Eine Anmeldung soll an verschiedenen Systemen möglich sein, wobei die verfügbaren Systeme als Liste angeboten werden sollen.”

inhaltlich verstehen und in seinem Bereich entsprechend handhaben, bewerten oder anderweitig einsetzen.

Ein Tester kann die Anforderung testen, ein Designer kann für sie die Spezifikation erstellen, ein Entwickler die GUI dafür programmieren, ein Fachspezialist die Systeme definieren und ein Manager planen wann sie in welcher Modulversion zur Verfügung steht und was das kostet. Alles im Rahmen des Moduls  isa.wb.Login-1.x.

  • das eine Spezifikation hat
  • die auf einer Anforderungsliste basiert
  • das ein Entwicklungsprojekt ist
  • das als Ergebnis eine Moduldatei (z.B. jar) im Repository ist 

2: So kann z.B. die Fachlichkeit unabhängig von Management und Technik die Anforderungslisten je nach ihren Bedürfnissen erweitern bzw. neue (Module) definieren um den Systemumfang zu vergrößern.

Das Management wiederum kann unabhängig von Fachlichkeit und Technik entscheiden, welche Anforderungen in welchen Modulversionen wann zu realisieren sind.

Die Technik kann kontinuierlich und unabhängig von der Fachlichkeit immer die Module bzw. Versionen spezifizieren, realisieren und warten, die gerade vom Management geplant sind.

3: Ein agiles Vorgehen kann leicht umgesetzt werden, weil die Modulanforderungsliste den in agilen Verfahren üblichen Anforderungslisten entspricht und Module bzw. deren Versionen hier  einen idealen Entwicklungsgegenstand darstellen, der in agilen Verfahren zunächst einmal fehlt (siehe auch Agile Vorgehen und Architektur).

Ein Produkt oder Gewerk lässt sich dabei genauso einfach darstellen. Es ist schlicht die Menge der spezifizierten und kalkulierten Module. Die Planung und das Controlling erfolgen dabei genauso über die entsprechenden Anforderungslisten der Module wie in agilen Verfahren. Das hat den Vorteil, das ein ganzes Produkt Top down von einfachen Anforderungslisten aus geplant werden kann – ohne bereits am Anfang genau wissen zu müssen wann und wie welche Anforderung umgesetzt wird.

Zudem ist die einzelne Anforderung ein idealer Gegenstand im Changemanagement, weil sie identifizierbare Fachlichkeit unabhängig von der Technik einfach plan- und steuerbar macht. Denn jede Änderung ist entweder eine neue oder eine geänderte Anforderung und damit automatisch in allen Bereichen eindeutig verortet.