Ein Szenario

Herr Gordon arbeitet bei Quasselcom – einem Unternehmen, das Mobiltelefone herstellt – in der Softwareentwicklung als Requirements Engineer. Er ist gerade mit der Spezifikation des neuen Adressbuches für eine neue Generation von Quasselcom-Mobiltelefonen beschäftigt. Da die Software für Mobiltelefone in den letzten Jahren immer komplexer geworden ist, sind mittlerweile über ein dutzend Teams in mehreren Abteilungen damit beschäftigt, fast zweihundert Spezifikationsdokumente zu erstellen, zu pflegen und konsistent zu halten.

Dabei haben sich immer wieder Probleme bezüglich der Abstimmung verschiedener Spezifikationen ergeben – insbesondere, wenn diese in der Verantwortung verschiedener Teams oder sogar verschiedener Abteilungen lagen: Teilweise war nicht eindeutig geregelt, wie Dokumente voneinander anhängen und wie sie konsistent gehalten werden. Mal sind die Begriffswelten in eigentlich inhaltlich zusammenhängenden Dokumenten so weit divergiert, dass eine Überprüfung der Konsistenz gar nicht mehr möglich war. Auch hatten sich die Spezifikationsverantwortlichen häufig erst viel zu spät mit einander abgestimmt, wodurch die erforderlichen Nacharbeiten dann entsprechend aufwändig waren und unter Zeitdruck durchgeführt werden mussten.

Um diesen Problemen zu begegnen, wurde bei Quasselcom die Verwendung von Funktionskatalogen zur Abstimmung von Spezifikationen eingeführt. Funktionskataloge stellen eine übersichtliche, formalisierte Methode zur Verknüpfung verschiedener Spezifikationen dar. Praktisch handelt es sich dabei um eine beliebig strukturierte Liste von eindeutig benannten Funktionen. Auf den ersten Blick hat sie Ähnlichkeiten mit einer API-Dokumentation aus dem Programmierumfeld – mit dem Unterschied, dass ein Funktionskatalog keine Dokumentation sondern ein Masterdokument darstellt. Ein Funktionskatalog ist eine gemeinsame Abstimmungsgrundlage für zusammenhängende Spezifikationen, die von unterschiedlichen Instanzen verantwortet werden.

Wenn zum Beispiel Herr Gordon eine neue Funktionalität des Adressbuches spezifiziern möchte, muss er zuerst den Funktionskatalog „FK_Addressbook_HMI“ überarbeiten. In diesem sind die Einigungen bezüglich der Funktionalität des Adressbuches zwischen dem Adressbuch-Verantworlichen (Herr Gordon) und der HMI-Verantwortlichen (Frau Archer) festgehalten. Die Einigungen beschränken sich allerdings auf die Aspekte, die von beiden Verantwortlichen benötigt werden – In diesem Beispiel also von der Adressbuch-HMI benötigte Funktionen, die vom Adressbuch zur Verfügung gestellt werden:

• FK-AB_GetFullListOfNames(Addressbook.Database)
• FK-AB_StartNameSearchByPrefix(Generic.Text)
• FK-AB_SetFirstName(AddressbookEntry, Generic.Text)
• …

Dabei bestehen Einträge im Funktionskatalog in erster Linie aus einem projektweit eindeutigen Namen und optional einer Menge von Funktionsparametern, die die für die Ausführung der Funktion nötigen Informationen bezeichnen. Die Benennung der Funktionsparameter wird dabei am besten aus dem Begriffsklassenmodell des Systems übernommen. Bei der Benennung der Funktionen sollte darauf geachtet werden, dass es sich um „sprechende“ Namen handelt – jeder Leser sollte den Namen der Funktion sofort einordnen können.

Für die Abstimmung mit der HMI nicht benötigte, interne Funktionen werden in diesem Katalog nicht beschrieben. Zum Beispiel ist eine Funktion zur Optimierung des Speicherbedarfs der Adressdatenbank nicht in „FK_Addressbook_HMI“ aufgeführt. Für jeweils zwei funktional miteinander verknüpfte Spezifikationen kann es einen eigenen Funktionskatalog geben. Funktionen, die für die Abstimmung mit anderen Softwareteilen des Mobiltelefons nötig sind – wie zum Beispiel der Austausch von E-Mail-Adressen mit der Messaging-Software, werden also auch nicht in „FK_Addressbook_HMI“ aufgeführt.

Bei der neuen Funktion, die Herr Gordon nun spezifizieren möchte, handelt es sich um einen neuen Anrufassistenten, der eine im Adressbuch gespeicherte Person nacheinander auf zwei gespeicherten Nummern zu erreichen versucht. Wobei die Reihenfolge der Nummern sowohl allgemein als auch individuell konfiguriert werden kann. Beispielkonfiguration: allgemein zuerst Diensthandy und dann Dienst-Festnetz, die Schwägerin zuerst auf dem Privat-Festnetz und danach auf dem Privathandy, da diese daheim arbeitet.

Der Funktionskatalog „FK_Addressbook_HMI“ muss also um eine Reihe weiterer Einträge erweitert werden. Da dieser für alle abhängigen Spezifikationen bindend ist, muss er als erstes überarbeitet werden. Sobald dies geschehen ist, können die beteiligten Spezifikationen unabhängig voneinander ausgearbeitet werden.

Herr Gordon einigt sich mit Frau Archer auf folgende neue Einträge:

• FK-AB_StartPhoneAssistant(AdressbookEntry)
• FK-AB_SetGenericPhoneAssistantFirstNumber(Addressbook.PhonenumberType)
• FK-AB_SetIndividualPhoneAssistantFirstNumber(AdressbookEntry, Addressbook.PhonenumberType)
• FK-AB_SetGenericPhoneAssistantSecondNumber(Addressbook.PhonenumberType)
• FK-AB_SetIndividualPhoneAssistantSecondNumber(AdressbookEntry, Addressbook.PhonenumberType)
• FK-AB_GetGenericPhoneAssistantFirstNumber
• FK-AB_GetIndividualPhoneAssistantFirstNumber(AdressbookEntry)
• FK-AB_GetGenericPhoneAssistantSecondNumber
• FK-AB_GetIndividualPhoneAssistantSecondNumber(AdressbookEntry)

Nun können sowohl Herr Gordon als auch Frau Archer unabhängig voneinander die Funktionalität und die Bedienung des Mobiltelefons spezifizieren. Herr Gordon spezifiziert z. B. wie dieser Assistent genau funktioniert, nach wieviel Sekunden zum Beispiel von der ersten auf die zweite Nummer umgeschaltet wird oder ob bei „besetzt“ die selbe Nummer mehrfach angerufen wird. Frau Archer dagegen spezifiziert, wo und wie die Konfiguration des Assistenten vorgenommen wird, ob man den Assistenten per Menüeintrag oder per Sprachbefehl starten kann, usw. Fällt jetzt bei der Spezifikation einem Verantwortlichen auf, dass bestimmte Detailfunktionen mit den bisherigen Einträgen nicht möglich sind, kann der Funktionskatalog – genau wie jede andere Spezifikation – im Rahmen eines Änderungsprozesses modifiziert werden. Möchte Frau Archer also für jeden Adressbucheintrag anhand eines Icons sichtbar machen, ob jeweils ein individueller Assistent konfiguriert wurde, kann sie sich mit Herrn Gordon zum Beispiel darauf einigen, folgen Eintrag noch mit hinzuzunehmen:

• FK-AB_GetIndividualPhoneAssistantStatus(AddressbookEntry)

Da in diesem Fall nicht sofort deutlich wird, was mit diesem Status gemeint ist, einigen sich Herr Gordon und Frau Archer, einen erläuternden Kommentar mit in den Funktionskatalog aufzunehmen:

• FK-AB_GetIndividualPhoneAssistantStatus(AddressbookEntry)
  • Provides information, whether an individual phone assistant is configured for a specific entry of the address book.

Das Pflegen der Funktionskataloge ist nicht sehr zeitaufwändig, da sie keine Spezifikationsdetails enthalten sondern nur eine Art „Schnittstelle“ zwischen zwei Spezifikationen definiert. Jeder Eintrag eines Funktionskataloges stellt die Signatur einer Funktion, die von einem Teil des Systems benötigt und von einem anderen Teil bereitgestellt wird, dar.

Dabei hat dieses Prinzip einen gewaltigen Vorteil gegenüber der direkten Verknüpfung zweier Spezifikationen (Stichwort: horizontale Traceability). Denn Funktionskataloge sind eigene Artefakte, die nicht einer verantwortlichen Instanz allein unterstehen, sondern vertragsähnlich zwischen zwei Parteien ausgehandelt werden. Sie sind gleichzeitig Begriffsdefinition und Erwartungsspezifikation, die für beide Seiten bindend ist.

Damit erlaubt dieses Prinzip auch die Verifikation von Spezifikationen gegen einen Funktionskatalog: Ob alle im Katalog definierten Funktionen von beiden Seiten weiter spezifiziert wurden, ist dank der festgelegten Bezeichnungen leicht nachzuvollziehen. Hat Frau Archer alle Funktionen des Assistenten in den Wireframes der HMI-Spezifikation und in der Menühierarchie berücksichtigt? Hat Herr Gordon das konkrete Verhalten aller Assistentenfunktionen beschrieben? Dank des Funktionskatalogs ist eine solche Überprüfung jederzeit möglich.

Nachwort

Die Geschichte von Quasselcom und den Funktionskatalogen ist so natürlich frei erfunden. Das Prinzip der Funktionskataloge ist eine Vision, die sich aus unserer Praxiserfahrungen bei verschiedenen Kunden ergeben hat. Was meinen Sie? Könnte diese weitere Art von Spezifikationsdokumenten die Abstimmung zwischen Spezifikationsteams in Ihrem Unternehmen verbessern? Wenn nein, woran krankt das Konzept? Wenn ja, haben Sie die Möglichkeit es auszuprobieren? Sparen Sie bitte nicht mit Kommentaren.