Teil II - Tango-Beschreibungsmethodik
3 Die Tango-Beschreibungsmethodik

3.1 Prinzipien und Herkunft

Zustandsveränderung als Beschreibungsprinzip

Die Tango-Beschreibungsmethodik betrachtet ein Produkt als System, das zu jedem Zeitpunkt einen definierten Zustand einnimmt, genannt Gesamtzustand. Einwirkungen auf das Produkt führen zu einer Veränderung dieses Gesamtzustandes. Das Produkt kann als Folge der Einwirkung selbst Wirkungen auf die Außenwelt erzeugen. Ohne eine Einwirkung von außen ist das Produkt komplett inaktiv, der Gesamtzustand verändert sich nicht.

Die Funktion des Produkts kann beschrieben werden, indem die Reaktionen des Produkts auf Einwirkungen von außen beschrieben werden, dies umfasst sowohl die Veränderungen des Gesamtzustandes als auch die Wirkungen auf die Außenwelt. Ein Zustandsübergangsdiagramm (synonym: Zustandsdiagramm) beschreibt diese Wirkzusammenhänge. Die Tango-Beschreibungsmethodik ist abgeleitet von den Zustandsübergangsdiagrammen, und eine Tango-Spezifikation kann prinzipiell auch durch Zustandsübergangsdiagramme ersetzt werden.

Unschärfe erzeugt höheren Nutzwert

Nicht jede Veränderung des Gesamtzustandes ist für die Funktion des Produkts von Bedeutung. Das Umfeld, in dem das Produkt arbeiten soll, wird als Domäne (oder Fachgebiet, Einsatzgebiet) bezeichnet. Die Domäne entscheidet, ob eine relevante Veränderung des Gesamtzustandes vorliegt oder nicht. Ein Zustand ist deshalb eine Abstraktion und umfasst eine Menge von tatsächlichen Varianten eines Gesamtzustandes.

Beispiel: Ein Taschenrechner, der zwei Zahlen addiert, reagiert aus Sicht der Domäne gleich, wenn er 25 + 10 oder 30 + 10 berechnen soll. Genau genommen ist der Taschenrechner in einem anderen Gesamtzustand, wenn 25 oder 30 eingetippt wurde. Von diesem Unterschied kann abstrahiert werden, weil sich das Gesamtverhalten des Taschenrechners nicht in relevanter Weise ändert. Die Entscheidung, welche Unschärfe ein Zustand einschließt, ist domänenspezifisch.

Ein Zustandsübergang im engen Sinn führt von einem Zustand in den nächsten. Ein abstrahierter Zustandsübergang führt von einem relevanten Zustand in den nächsten, wobei Zwischenschritte und Zwischenzustände aus Sicht der Domäne nicht relevant sind und deshalb ignoriert werden. Der Zielzustand eines Zustandsübergangs ist bekannt, wenn alle Randbedingungen bekannt sind, die für den Zustandsübergang relevant sind. Bei der Beschreibung eines Produkts sind, anders als beim tatsächlichen Ablauf, alle Randbedingungen vorab bekannt. Damit ist die Zusammenfassung von Zustandsübergängen zu größeren Schritten möglich..

Beispiel: Das Eingeben von 15 / 3 = in den Taschenrechner führt zu einem Rechenergebnis, die Eingabe 15 / 0 = liefert einen Fehler. Aus Sicht der Domäne ist nur relevant, dass ein Ergebnis in eine von zwei möglichen Ergebniskategorien gehört, entweder das korrekte Berechnungsergebnis, oder eine Fehlermeldung. Auf welchem Weg diese Ergebnisse zu Stande kommen, und ob dazu Zwischenschritte oder Zwischenzustände notwendig waren, ist irrelevant.

Die Betrachtung des Produkts von der Aufgabe aus, die es in der Domäne erfüllt (den Requirements), vereinfacht die Beschreibung des Produkts. Die Beschreibung kann sich auf den direkten Zusammenhang von Ursache und Wirkung konzentrieren, wenn Implementierungsdetails außer Acht gelassen werden. Varianten des Gesamtzustandes werden zu abstrakten Zuständen zusammengefasst und Zwischenschritte sowie Zwischenzustände bleiben unberücksichtigt. Die Beschreibung wird kompakter, und unnötige Randbedingungen für eine spätere Implementierung werden vermieden.

Einarbeiten von Lerneffekten

Das Arbeiten an und mit dem Produkt führt zu neuen Erkenntnissen über die Eigenschaften dieses Produkts. Im Verlauf der Produktentwicklung wird sich herausstellen, dass die Spezifikation angepasst werden muss. Dies ist in großem Umfang notwendig, wenn Implementierungsdetails Teil der Spezifikation geworden sind. Auch in einer weitgehend implementierungsfreien Spezifikation werden sich einige Eigenschaften ändern, weil zusätzliche Anforderungen an das Produkt entstehen, oder weil bestimmte Aspekte neu interpretiert werden müssen. Soll die Spezifikation weiterhin als Basis der Entwicklung dienen, so müssen diese neuen Erkenntnisse eingearbeitet werden.

Die Notwendigkeit, Änderungen schnell einarbeiten zu können, führt zur rein textorientierten Tango-Beschreibungssprache. Das Einfügen von Zeilen in einen vorhandenen Text ist weniger aufwändig als das Ergänzen und Neuorganisieren einer grafischen Darstellung. Ungeachtet der eingeschränkten Nützlichkeit beim Eingeben der Information kann das nachträgliche bildliche Visualisieren der Zusammenhänge aus einer Tango-Spezifikation Sinn machen.

Die Texteinrückung ist ein relevantes Strukturierungsmerkmal der Tango-Beschreibungssprache, mit dem Über- und Unterordnung von Information dargestellt wird. Die Verwendung von Klammern für diesen Zweck wäre weniger effizient, denn durch die Einrückung wird sofort sichtbar, wo Änderungen platziert werden, statt vorher die Anzahl öffnender und schließender Klammern prüfen zu müssen.

Die Fähigkeit, Änderungen schnell einzuarbeiten, wird als wesentliches Qualitätsmerkmal von Spezifikationen betrachtet, denn nur so kann eine Spezifikation mit akzeptablem Aufwand aktuell gehalten werden. Die Tango-Beschreibungssprache wurde in Hinblick auf die kontinuierliche Pflege einer Spezifikation optimiert.

Lokale Beschreibung statt Gesamtzustand

Zustandsübergangsdiagramme beschreiben die Veränderung des Gesamtzustandes eines Systems. Die Verfeinerung erfolgt, indem aus dem System Teilsysteme abgeleitet werden, deren gegenseitige Abhängigkeit hinreichend gering ist, so dass ein eigenes Diagramm für jedes Teilsystem aussagekräftig ist. Die Sicht auf den Gesamtzustand des Systems führt zu einem hohen Aufwand, wenn Zustandsübergangsdiagramme an geänderte Anforderungen angepasst werden müssen.

Die Tango-Beschreibungsmethodik orientiert sich nicht am Gesamtzustand, sondern an den Wirkungen, die als Folge von Zustandsübergängen auftreten. Die Tango-Spezifikation besteht weitgehend aus lokal eng begrenzten Aussagen. Aus Sicht der Zustandsübergangsdiagramme werden nur Anfang und Ende der Zustandsübergangspfeile betrachtet, und auch die erreichten Zustände bleiben weitgehend unbestimmt. Durch Auswertung der beschriebenen Wirkungen über die ganze Spezifikation hinweg lässt sich die Veränderung des Gesamtzustands und letztlich das Zustandsübergangsdiagramm des Produkts ermitteln, denn die gesamte Information dazu ist in der Tango-Spezifikation vorhanden.

Die lokal begrenzte Sicht der Tango-Beschreibungsmethodik erleichtert die Pflege der Spezifikation, da nur lokale Wirkungen betrachtet und verändert werden müssen. Die lokale Sicht entspricht auch der Sicht des Anwenders auf das Produkt, der sich gewöhnlich nicht um die Befindlichkeit des gesamten Produkts kümmern will, sondern der eine bestimmte Leistung vom Produkt erwartet und sich deshalb nur für einen speziellen Teil des Produkts interessiert. Der Gesamtzustand des Produkts ist aus Tango-Sicht ein abstraktes Konzept, das im Regelfall in einer Beschreibung nicht verwendet werden muss.

Ereignisse entgegennehmen

Um Einwirkungen auf das Produkt verarbeiten zu können werden Aktivatoren zur Verfügung gestellt. Jeder Aktivator kann ein bestimmtes Ereignis entgegennehmen, und dieser Vorgang löst Aktivitäten im Produkt aus.Die Wirkung dieser Aktivitäten wird in Aktivitätsblöcken beschrieben. Aktivitätsblöcke beschreiben den aktiven Teil des Produkts, nur in diesen Blöcken kann der Gesamtzustand des Systems verändert werden.

Aktivitätsblöcke sind keine Prozeduren, die beim Eintreffen eines Ereignisses ausgeführt werden, sie sind vielmehr eine Checkliste von Wirkungen, die nach dem Auslösen eines Aktivators eingetreten sein müssen. Aktivitätsblöcke werden also nicht durchlaufen, sondern genutzt zur Beschreibung von Wirkungen. In einem Aktivitätsblock können Teilzustände des Systems in einer Verzweigung abgefragt werden, und abhängig davon werden andere Aktivitätsblöcke genutzt, in denen weitere Wirkungen beschrieben sind.

Die Tango-Beschreibungsmethodik kann nur Ergebnisse beschreiben, keine durchzuführenden Operationen. Die Beschreibung von Vorgängen ist also immer posthum, es wird die Wirkung von Vorgängen betrachtet, und nicht deren Ausführung. Normalerweise besteht ein Aktivitätsblock aus einer Aufzählung von Wirkungen in beliebiger Reihenfolge. Wenn die Reihenfolge der Wirkungen relevant ist, dann wird in einem Aktivitätsblock eine Sequenz von Wirkungen beschrieben.

Zustände und Gesamtzustand

Der Gesamtzustand und alle seine Teilzustände können in Aktivitätsblöcken genutzt werden. Das Abfragen und Ändern von Teilzuständen ist jederzeit und unbegrenzt möglich, ohne dass der Gesamtzustand in irgendeiner Form näher zergliedert sein müsste. Auf jeden Aspekt des Gesamtzustandes kann auf beliebige Weise zugegriffen werden, in Form einer vagen Andeutung bis hin zur detaillierten Beschreibung der Änderung im Gesamtzustand.

In vielen Fällen genügt es, den Gesamtzustand oder einen nicht näher bestimmten Teil davon formlos zu beschreiben, um in der Spezifikation darauf zugreifen zu können. Daneben gibt es Situationen, in denen ein Teilzustand genau identifiziert werden muss:

• die Wirkzusammenhänge an einem Teilzustand sollen explizit dargestellt werden, so dass jede Veränderung oder Nutzung genau beschrieben und verfolgt werden kann.
• die Eigenschaften eines Teilzustands sollen näher spezifiziert werden, z.B. welche Werte der Teilzustand annehmen kann, oder wie die komplexe Datenstruktur dahinter aussehen soll.

In diesen Fällen wird ein Zustand definiert, der einen Ausschnitt aus dem Gesamtzustand repräsentiert. Dieser Zustand ergänzt nicht den Gesamtzustand, er macht lediglich einen Teil dieses Gesamtzustandes leichter zugänglich. Ein kleines Teil wird aus dem Gesamtzustand herausgezogen und markiert, und damit ist dieses Teil identifizierbar und steht für die weitere Bearbeitung zur Verfügung.

Die Tango-Beschreibungsmethodik spricht von einem Zustand und meint damit die Kombination aus einem bestimmten Aspekt des Gesamtzustandes und dem Wert, mit dem dieser Aspekt zu einem Zeitpunkt beschrieben werden kann. Die Kombination aus Wert und Werthalter macht den Zustand aus. Die Aussagen "Das System geht in einen neuen Zustand" und "Der Zustand erhält einen neuen Wert" werden als synonym betrachtet.

Einwirkung von außen auf das Produkt

Das Produkt nimmt Ereignisse ausschließlich an Aktivatoren entgegen, dies löst Vorgänge im Produkt aus, deren Wirkungen in den Aktivitätsblöcken beschrieben werden. Daneben gibt es Information, die dem System von außen zur Verfügung gestellt wird, ohne dass dies mit einem Ereignis verbunden ist. Dem Produkt steht dann frei, ob und wann es auf diese Information zugreifen will, dies wird erst dann geschehen, wenn die Information für die Bearbeitungsvorgänge benötigt wird.

Im Bild der Tango-Beschreibungsmethodik ist das Produkt umgeben von einer Wolke aus Informationen, die von anderen Systemen zur Verfügung gestellt werden. Dieses Gebilde wird als EXTERN-Wolke bezeichnet und kann als gepufferte Schnittstelle verstanden werden, in die jedes andere System Information abladen kann, die für das Produkt bestimmt ist. Bei Bedarf holt sich das Produkt die gewünschte Information aus der Wolke. Das Produkt kümmert sich nicht darum, wie die Information in die Wolke kommt, die Existenz der gewünschten Information wird vorausgesetzt.

Genau wie beim Gesamtzustand gibt es Teilinformation in der Wolke, die unter bestimmten Umständen genauer identifiziert werden sollte. Mögliche Gründe sind:

• Die Lieferung der Information ist aus Sicht der Domäne ein eindeutig festgelegtes Verfahren, und diese Vorgehensweise ist Teil der Anforderung, die mit der Spezifikation beschrieben wird. Typisches Beispiel dafür ist die Eingabe von Information über eine grafische Oberfläche. Es ist aus Sicht der Domäne relevant, dass ein Kundenname in einem Eingabetextfeld eingegeben wird und nicht auf irgendeine andere Weise.
• Die Lieferung der Information ist mit Ereignissen verbunden, die unter bestimmten Umständen ausgelöst werden können. Dieser Zusammenhang soll beschrieben werden. Ein Beispiel dafür wäre eine Alarmmeldung, die ein sofortiges Reagieren des Systems erfordert.
• Die Lieferung der Information erfolgt im Dialog mit dem Lieferanten der Information, und dieser Dialog soll in der Spezifikation beschrieben werden. Ein Beispiel ist Information, die nur im korrekten Format angeliefert werden darf. Wenn die Information im falschen Format vorliegt, dann wird die Information abgelehnt und der Lieferant wird davon unterrichtet.

Zugelieferte Informationen und deren verwaltende Konstrukte können in der Tango-Spezifikation explizit beschrieben werden, so dass nicht mehr auf die EXTERN-Wolke zugegriffen werden muss. Auf diese Weise werden z.B. Eingabetextfelder und Checkboxen einer grafische Oberfläche zum Bestandteil der Spezifikation. Anders als Zustände sind diese verwaltenden Konstrukte keine Bestandteile der Tango-Beschreibungsmethodik, sie werden vielmehr aus dem Wissen um die Domäne abgeleitet und als Konvention vereinbart. Die Tango-Beschreibungssprache stellt mit den Spezialisierungprefixen ein Mittel zur Verfügung, solche Konstrukte zu bezeichnen.

Wirkung des Produkts nach außen

Das Produkt erzeugt Wirkungen auf die Umgebung. Die Wirkung kann ein Ereignis sein, das am Aktivator eines fremden Systems ausgelöst wird. Das Auslösen des Aktivators erfolgt asynchron, es wird also vom fremden System keine Reaktion erwartet.

Information kann an ein fremdes System gesendet werden. Damit wird diese Information in die EXTERN-Wolke des fremden Systems eingestellt, das fremde System kann bei Bedarf auf diese Information zugreifen. Das direkte Verändern eines Zustands am fremden System ist nicht möglich, da der innere Aufbau des fremden Systems in der Tango-Spezifikation nicht beschrieben ist.

Durch Senden von Information an einen Aktivator eines fremden Systems kann die Information in die EXTERN-Wolke des Empfängers eingestellt werden, gleichzeitig wird der Aktivator des Empfängers ausgelöst. Die Existenz dieses Aktivators im fremden System wird vorausgesetzt. Der gesamte Vorgang ist asynchron, das Produkt erwartet keine Reaktion vom Empfänger.

Ein fremdes System, das durch das Auslösen eines Aktivators zu einer Aktivität angeregt wurde, kann eine Rückmeldung an das Produkt geben, z.B. ob die Aktivität erfolgreich war, oder einen beliebigen anderen Wert. Wird diese Rückmeldung im Produkt weiterverarbeitet, z.B. als zu prüfender Wert in einer Verzweigung, so muss das Produkt warten, bis das fremde System seine Aktivitäten beendet hat und antwortet, der Vorgang wird synchron.

Das Produkt kann eine Information an ein fremdes System senden, und dann auf eine Antwort warten. Auf diesem Weg bleibt offen, ob das fremde System sofort, mit großer Verzögerung oder überhaupt nicht antwortet. Diese Kommunikation ist ebenfalls synchron, jedoch muss das Produkt die Möglichkeit einer zu späten oder ausbleibenden Antwort in seinen weiteren Abläufen berücksichtigen.

Wirkungen aus Aktivitäten des Produkts können am Produkt selbst zur Verfügung gestellt werden, sie müssen nicht unbedingt an einen bestimmten Empfänger adressiert sein. In welcher Weise dies geschehen soll, hängt von der Domäne ab, entsprechende Konstrukte können vereinbart und mit Spezialisierungsprefixen bezeichnet werden. Auf diese Weise kann z.B. das Rechenergebnis eines Taschenrechners in einem Textfeld zur Verfügung gestellt werden. Das Ergebnis wird nicht an einen bestimmten Empfänger versandt, sondern dieser Teil des Gesamtzustands des Produkts wird für alle lesbar nach außen sichtbar gemacht.

3.2 Anwendung der Tango-Beschreibungsmethodik

Umfang der Tango-Spezifikation

Die Tango-Beschreibungsmethodik geht von einem kooperativen Umfeld aus. Die nicht beschriebene Welt rund um das Produkt verursacht nichts, was die Arbeit des Produkts überraschend und ungeplant beeinflussen könnte. Dies führt zu Annahmen, die in den vorigen Kapiteln bereits teilweise erwähnt wurden:

• Einwirkungen auf das Produkt erfolgen nur über Aktivatoren,
• alle benötigten Informationen stehen bei Bedarf zur Verfügung,
• alle benötigten Aktivatoren an fremden Systemen sind vorhanden,
• jede versandte Information wird verstanden,
• jede erhaltene Information ist sinnvoll und verwertbar.

Die Folge dieser Annahmen ist, dass nicht nur das Produkt, sondern auch das Arbeitsumfeld des Produkts genau betrachtet werden muss, denn Probleme, die im Arbeitsumfeld entstehen, können nur berücksichtigt werden, wenn sie auch beschrieben sind. Die Ursache-Wirkungs-Zusammenhänge im Umfeld des Produkts müssen nicht aufgedeckt werden, aber es muss bekannt sein, welche möglichen Reaktionen von der Umwelt zu erwarten sind.

Beispiel: Ein Produkt führt eine Datenbank-Anfrage durch, die Datenbank selbst ist nicht Teil des Produkts. Das Produkt muss wissen, wie die Anfrage durchgeführt wird, und welche möglichen Ergebnisse kommen können. Wenn manche Anfragen einen Fehler liefern, dann ist nicht von Interesse, welche Parameterwerte der Anfrage zu einem Fehler führen, sondern nur, dass die Antwort auf die Anfrage prinzipiell auch ein Fehler sein könnte.

Die erwartete Reaktion eines fremdem Systems auf ein Ereignis könnte im Fehlerfall auch völlig ausbleiben. Um dieses Verhalten kooperativ nachzubilden, wird angenommen, dass das fremde System den Wert "ich antworte nicht" zurückliefert.

Eine Tango-Spezifikation beschreibt nicht nur das Produkt, sondern auch das Umfeld, in dem dieses Produkt arbeitet. Sie enthält eine vollständige Beschreibung der Schnittstelle zwischen dem Produkt und der Umwelt.

Gegenstand der Beschreibung

Die Tango-Beschreibungsmethodik ist abgeleitet vom Zustandsübergangsdiagramm, und sie kann angewendet werden auf alles, was durch Zustandsübergänge beschrieben werden kann. Das zu beschreibende Produkt kann sein:

• Hardware, jedes Gerät das mit einem menschlichen Nutzer oder anderen Geräten interagiert,
• eine Softwareanwendung mit einer Benutzerschnittstelle, grafisch oder über Kommandozeile,
• eine Software, die mit anderer Software oder Hardware interagiert,
• eine abstrakte Vereinbarung von Interaktionen z.B. ein Kommunikationsprotokoll, oder eine abstrakte Schnittstelle, bei der nicht nur der funktionale Aspekt, sondern auch Abläufe beschrieben werden sollen,
• eine Vereinbarung über die Struktur einer Beschreibung, z.B. ein Dateiformat oder eine Beschreibungssystematik, die anschließend in XSL implementiert werden könnte,
• eine Verfahrensweise, z.B. eine Herstellungsanweisung, wenn der Ablauf selbst, und nicht die Synchronisation von Prozessen innerhalb des Ablaufs im Vordergrund steht.

Die Tango-Beschreibungsmethodik erlaubt, Information jeder Art in einen formalen Rahmen einzuordnen. Die eingebundene Information kann formlos sein, sie muss keine tangospezifischen Kriterien erfüllen, außer dass das Ende des formlosen Informationsblocks erkennbar ist. Deshalb kann prinzipiell jede Beschreibung als Tango-Spezifikation strukturiert werden, es gibt keine inhaltlichen Einschränkungen, insbesondere nicht in Hinblick auf zunehmende Detaillierung und Nähe zur Implementierung. Es gibt auch keine Beschränkung auf Text in einem formlosen Informationsblock. Obwohl die Tango-Beschreibungsmethodik textuell strukturiert ist, könnten multimediale Inhalte im formlosen Informationsblock enthalten sein. Die Grenzen werden nur durch Werkzeuge gesetzt, die mit der Tango-Spezifikation arbeiten sollen, nicht durch die Beschreibungsmethodik selbst.

Die Grenze der sinnvollen Anwendung von Tango ist erreicht, wenn die formalen Kriterien einer Beschreibung an Bedeutung zunehmen. An diesem Punkt ist der Wechsel auf stärker formalisierte Beschreibungsmethoden empfehlenswert. Dies wird im Verlauf einer Software-Entwicklung gewöhnlich notwendig, wenn die Analysephase in die Designphase übergeht. Werkzeuge für die Designphase und solche für die Analysephase sind wechselseitig nicht austauschbar, da die Anforderungen an die Struktur der Information auf den Entwicklungsebenen stark unterschiedlich sind. Der Versuch, mit ein und demselben Werkzeug beide Entwicklungsphasen abzudecken zur Vermeidung eines "Medienbruchs", führt zur ineffizienten Arbeit in einer dieser Phasen.

Vorgehensweise bei der Spezifikation mit Tango

Die Tango-Beschreibungsmethodik konzentriert sich auf die lokale Beschreibung von Effekten in und an einem Produkt. Deshalb ist der Umstand, dass hinter Tango die Beschreibung durch Zustandsübergangsdiagramme steht, bei der Erstellung von Spezifikationen für Hardware und Software nicht von primärer praktischer Bedeutung. Die Beschreibung konzentriert sich stattdessen auf die von außen sichtbaren Wirkungen, und wird dann erweitert auf die inneren Zusammenhänge, die diese Wirkung erklären.

Im Falle, dass ein bereits vorhandenes Produkt beschrieben werden soll, um einen Test zu erstellen, wäre die folgende Zusammenstellung eine typische Vorgehensweise. Die einzelnen Schritte können auf Teilsysteme des Produkts angewandt und mehrfach iterativ durchlaufen werden:

• Bestandsaufnahme aller Elemente der Schnittstelle zum Anwender.Welche Darstellungs- und Bedienelemente gibt es, was wird dort angezeigt, welche können zusammengefasst werden z.B. ein Zifferntastenblock.
• Bestandsaufnahme aller Schnittstellen zu anderen Systemen aus funktionaler Sicht. Welche Dienstanfragen können an das Produkt gestellt werden, welche Anworten sind zu liefern, welche Information stellt das Produkt zur Verfügung und wo. Anfragen des Produkts an andere Systeme müssen an dieser Stelle noch nicht vollständig erfasst sein, dies ergibt sich bei der Spezifikation der Aktivitätsblöcke.
• Unterschiedliche Rollen von Darstellungs- und Bedienelementen, z.B. ein nummerisches Textfeld am Kopier-Faxgerät zeigt die Faxnummer oder die Anzahl der Kopien, ein Abbrechen-Knopf beendet unterschiedliche Vorgänge, je nach Arbeitszustand. Daraus ergeben sich zusätzliche Bedienelemente und einige Zustände, die das Produkt einnehmen kann.
• Beschreibung der Aufgaben, die mit diesem Produkt erfüllt werden (Usecase).
• Beschreibung des Anfangszustandes und wie er erreicht wird, z.B. Einschalten des Gerätes.
• Ergänzen der Aktivitätsblöcke, die das Verhalten des Produkts erklären, dabei können weitere Zustände des Produkts sichtbar werden und die Anfragen des Produkt an fremde Systeme werden vervollständigt.
• Sammeln der nicht-funktionalen Anforderungen an das Produkt, z.B. Durchsatz, garantierte Antwortzeiten.

Die Spezifikation eines noch nicht vorhandenen Produkts in der Analysephase läuft prinzipiell nach dem gleichen Schema, mit folgenden Abweichungen:

• Die Zusammenstellung der Usecases steht an erster Stelle, bevor über eine Schnittstelle nachgedacht wird.
• Die Darstellungs- und Bedienelemente werden zuerst abstrakt nach Bedarf formuliert. Die Zusammenfassung zu Elementen, die verschiedene Rollen spielen, erfolgt erst, wenn die Vorstellung von der künftigen Benutzeroberfläche hinreichend stabil geworden ist.
• Eine Kontrolle der bisher erstellten Produktbeschreibung ist immer wieder notwendig, dabei wird überprüft, ob das durch die Usecases vorgegebene Ziel mit den bisher beschriebenen Aktivitätsblöcken erreicht werden kann.
• Es ist zu prüfen, ob die im Verlauf der Spezifikation postulierten Zustände des Produkts korrekt administriert werden, andernfalls müssen Usecases für diesen Zweck hinzugefügt oder funktionell erweitert werden.
• Entfernen unnötiger implementierungsrelevanter Details aus der Spezifikation.

Soll eine abstrakte Schnittstelle oder ein Protokoll beschrieben werden, so empfiehlt sich eine Top-down-Vorgehensweise, wobei die erste grobe Beschreibungsebene im Wesentlichen aus dem Ziel besteht, das mit diesem Protokoll erreicht werden soll ("Ich sende eine Datei zu einem bekannten Empfänger und kriege eine Quittung, dass alles OK ist."). Die Verfeinerung ergibt sich dann aus den Fragen "In welchen Schritten soll das ablaufen?" und "Was kann dabei schiefgehen?".