Funktionale Anforderungen, Qualitätsmerkmale und Randbedingungen

Drei Arten von Anforderungen

Eine Anforderung ist alles, was ein System erfüllen muss, um für seine Stakeholder akzeptabel zu sein. Architekten finden es nützlich, Anforderungen in drei Arten einzuteilen, weil jede Art das Design auf andere Weise beeinflusst. Eine funktionale Anforderung sagt, was das System tun muss: „Ein Kunde kann einen Artikel in den Warenkorb legen“, „das Apothekensystem prüft jedes neue Rezept gegen die Allergien des Patienten“, „ein Fahrgast kann die Position des Fahrers auf einer Karte sehen“. Funktionale Anforderungen beschreiben Verhalten, Daten und die Regeln, die beide verbinden. Sie sind das, was die meisten User Stories und Use Cases erfassen.

Ein Qualitätsmerkmal sagt, wie gut das System es tun muss. „Suchergebnisse erscheinen innerhalb einer halben Sekunde“, „der Buchungsservice ist zu 99,95 % der Zeit verfügbar“, „ein neuer Zahlungsanbieter lässt sich in weniger als zwei Wochen anbinden“, „Patientenakten sind nur für die behandelnden Ärztinnen und Ärzte lesbar“. Qualitätsmerkmale sind Eigenschaften des Systems als Ganzes oder einer Funktion, und sie ergeben nur mit einem Maß einen Sinn: schnell genug für wen, unter welcher Last, wie gemessen?

Eine Randbedingung ist eine Entscheidung, die bereits für Sie getroffen wurde. „Das System muss im bestehenden Azure-Tenant des Unternehmens laufen“, „alle personenbezogenen Daten bleiben in der Europäischen Union“, „das Team kann Java und hat kein Budget für Umschulungen“, „das erste Release muss live sein, bevor das Steuerjahr am 6. April beginnt“. Randbedingungen entfernen Optionen, statt Verhalten zu beschreiben. Innerhalb des Projekts sind sie nicht verhandelbar, doch ein guter Architekt prüft, ob jede wirklich eine Randbedingung ist und nicht bloß eine Gewohnheit oder Annahme.

Die Grenzen sind nicht immer scharf, und das ist in Ordnung. Der Sinn der Einteilung ist keine bürokratische Ordnung; sie soll sicherstellen, dass niemand fünfzig User Stories sammelt und vergisst zu fragen, wie viele Nutzer es geben wird, wie lange das Unternehmen einen Ausfall überlebt oder welche Aufsichtsbehörde zusieht.

Warum viele Architekten den Begriff „nichtfunktionale Anforderungen“ meiden

Anforderungsdokumente teilen traditionell alles in funktionale und nichtfunktionale Anforderungen (NFRs) ein. Der Begriff ist überall, in Verträgen, Ausschreibungsunterlagen und Stellenanzeigen, deshalb müssen Sie ihn kennen. Viele Architekten und Forschende meiden ihn dennoch, aus drei Gründen.

Erstens definiert er eine große und wichtige Kategorie über das, was sie nicht ist. Alles, was keine Funktion ist, landet im selben Topf: Antwortzeiten, Verschlüsselungsregeln, die Wahl des Cloud-Anbieters und die Farbe des Logos. Martin Glinz’ Paper On Non-Functional Requirements (IEEE International Requirements Engineering Conference, 2007) zeigte, dass veröffentlichte Definitionen uneins sind, was in die Kategorie gehört, und dass derselbe Bedarf je nach Formulierung so oder so eingeordnet werden kann: „Nur berechtigte Mitarbeitende dürfen Gehälter sehen“ liest sich als Funktion, wenn es als Zugriffsregel formuliert ist, und als Qualität, wenn es als Sicherheitsziel formuliert ist.

Zweitens legt der Name nahe, diese Anforderungen seien von den Funktionen getrennt und könnten später ergänzt werden. Das geht nicht. Ein Qualitätsmerkmal qualifiziert eine Funktion: Es ist der Bezahlvorgang, der schnell sein muss, die Zahlung, die nie verloren gehen darf, die Patientenakte, die vertraulich sein muss. Bass, Clements und Kazman sprechen in Software Architecture in Practice deshalb von Qualitätsmerkmal-Anforderungen und behandeln Randbedingungen als eigene Kategorie.

Drittens klingt „nichtfunktional“ optional, als ob ein System, das zwar läuft, aber langsam, unsicher oder nicht änderbar ist, trotzdem „funktioniert“. In der Praxis sind genau das die Systeme, die neu geschrieben werden. Manche Teams sagen lieber „Qualitätsanforderungen“; andere, vor allem bei Thoughtworks, sagen „Cross-Functional Requirements“, um zu betonen, dass sie quer durch alle Features gehen. Dieser Kurs spricht von Qualitätsmerkmalen und Randbedingungen. Wenn Ihre Organisation NFRs sagt, müssen Sie nicht um das Wort streiten; achten Sie nur darauf, dass jede NFR entweder eine messbare Qualität oder eine klar formulierte Randbedingung ist.

Randbedingungen: technisch, organisatorisch, regulatorisch, zeitlich und budgetär

Randbedingungen verdienen mehr Aufmerksamkeit, als sie meist bekommen, weil sie oft mehr von der Architektur bestimmen als jedes Feature. Eine Randbedingung ist einfach eine Anforderung ohne verbleibenden Spielraum. Es hilft, sie nach ihrer Herkunft zu gruppieren.

Zwei Gewohnheiten helfen. Erstens: Notieren Sie die Quelle jeder Randbedingung (eine Vorschrift, einen Vertrag, eine namentlich genannte entscheidende Person), damit sie geprüft und bei veränderten Umständen neu bewertet werden kann. Zweitens: Unterscheiden Sie echte Randbedingungen von Vorlieben, die sich als Randbedingungen ausgeben. „Wir müssen Microservices verwenden“ ist selten eine Randbedingung; es ist eine Designentscheidung, die jemand früh getroffen hat, und sie sollte wie jede andere Entscheidung durch Qualitätsmerkmale begründet werden. Der Abschnitt in Kapitel 1 über Entscheidungen und Abwägungen erklärt, warum frühe, schwer umkehrbare Entscheidungen diese Prüfung verdienen.

Architekturrelevante Anforderungen

Die meisten Anforderungen wirken sich nicht auf die Architektur aus. Ob auf der Rechnung die Postleitzahl des Kunden über oder unter dem Straßennamen steht, ist ein Detail; das lässt sich an einem Nachmittag ändern. Eine architekturrelevante Anforderung (ASR) ist eine, die eine messbare Wirkung auf die Architektur hat: Würde sie sich ändern, müsste sich die Struktur des Systems ändern. ASRs früh zu erkennen ist wichtig, weil es teuer ist, sie spät zu berücksichtigen. Einer Ticketseite eine Woche vor dem Verkauf einen Warteraum hinzuzufügen ist möglich; den Sitzplatzbestand nach dem Start über Server zu partitionieren ist eine Neuentwicklung.

Lianping Chen, Muhammad Ali Babar und Bashar Nuseibeh befragten Praktiker, wie sie ASRs erkennen (Characterizing Architecturally Significant Requirements, IEEE Software, 2013). Ihre Ergebnisse decken sich mit der Erfahrung der meisten Architekten. ASRs sind meist schwer zu erfüllen, betreffen oft das System als Ganzes statt eines einzelnen Features, stehen häufig miteinander im Konflikt und werden oft vage oder gar nicht formuliert. Qualitätsmerkmale und Randbedingungen machen die Mehrheit aus, aber auch manche funktionalen Anforderungen sind relevant.

Beispiele für funktionale ASRs: „Jede Änderung an einer Patientenakte muss einer Person und einem Zeitpunkt zuordenbar sein“ (das erfordert einen Audit-Mechanismus über alle Komponenten), „Nutzer können in Echtzeit am selben Dokument zusammenarbeiten“ (das verlangt ein Synchronisationsmodell und wahrscheinlich einen anderen Kommunikationsstil) und „Kunden können eine Überweisung innerhalb von 30 Minuten rückgängig machen“ (das betrifft, wie Geld zwischen Konten bewegt wird). Jede davon erzwingt eine strukturelle Entscheidung, nicht bloß mehr Code.

Warum Qualitäten die Architektur stärker prägen als Funktionen

Hier ist der zentrale Gedanke dieses Kapitels. Käme es nur auf die Funktionalität an, wäre fast jede Struktur recht: Man könnte das ganze System als ein großes Programm schreiben, und es würde trotzdem die richtigen Ergebnisse berechnen. Bass, Clements und Kazman sagen das direkt: Funktionalität bestimmt die Architektur nicht, weil viele verschiedene Architekturen dieselben Funktionen liefern können. Was sie unterscheidet, ist, wie gut jede die Qualitäten erreicht.

Betrachten Sie zwei Ticketsysteme mit identischen Features: Veranstaltungen ansehen, Plätze reservieren, bezahlen. Das eine verkauft Tickets für einen Gemeindesaal mit 300 Plätzen, das andere eine Stadiontournee mit 60.000 Plätzen. Der geschäftigste Moment des Gemeindesaals bringt vielleicht ein paar Anfragen pro Sekunde, und eine einzelne Webanwendung mit einer Datenbank ist die richtige Antwort: günstig, einfach und leicht zu ändern. Die Stadiontournee muss einen tausendfach größeren Ansturm abfangen, darf nie denselben Platz zweimal verkaufen und muss verhindern, dass Bots in der ersten Sekunde alles aufkaufen. Dieses System braucht ein Content Delivery Network, eine Warteschlange vor dem Shop, einen sorgfältig entworfenen Sitzplatzbestand, partitionierte Speicherung und einen Zahlungsablauf, der auf einen überlasteten Anbieter warten kann. Gleiche Funktionen, völlig verschiedene Architekturen, und der Unterschied kommt allein von Qualitätsmerkmalen und Randbedingungen.

Implizite Qualitäten, die niemand aufschreibt

Einige der wichtigsten Qualitäten werden nie formuliert, weil alle Stakeholder sie voraussetzen. Diese impliziten Anforderungen treten erst zutage, wenn sie verletzt werden, meist im Produktivbetrieb. Niemand schreibt „keine Bestellungen verlieren“, „dem Kunden nicht doppelt abbuchen“, „bei der Zeitumstellung weiterlaufen“, „auf dem Smartphone und der Website denselben Kontostand zeigen“ oder „die Daten eines Kunden nicht an einen anderen preisgeben“. Doch jede davon ist eine ASR mit schweren Folgen: idempotente Zahlungsverarbeitung, dauerhafte Schreibvorgänge, zeitzonensichere Terminplanung, Konsistenz zwischen den Kanälen und strikte Mandantentrennung.

Implizite Anforderungen bleiben aus sozialen Gründen verborgen. Fachliche Stakeholder halten sie für zu selbstverständlich, um sie zu erwähnen; Entwickler nehmen an, jemand anderes habe sich darum gekümmert; und Anforderungsvorlagen fragen selten danach. Nützliche Fragen, um sie aufzuspüren, sind: „Was würde Sie rasend machen, wenn es passierte?“, „Was würde uns in die Zeitung bringen?“, „Was ist bei dem System, das wir ablösen, schiefgegangen?“ und „Wofür wird das Betriebsteam nachts geweckt?“. Vorfallberichte und Support-Tickets von Vorgängersystemen sind eine reiche Quelle, ebenso die veröffentlichten Leitlinien von Aufsichtsbehörden und die Pflichten aus Kundenverträgen.

Wie Fachleute mit ASRs arbeiten

Erfahrene Architekten führen eine kurze, lebendige Liste von ASRs, typischerweise fünf bis fünfzehn Einträge, statt eines langen Anforderungsdokuments. Jeder Eintrag formuliert die Qualität als testbares Szenario (Abschnitt 2.3), nennt den Stakeholder, dem sie wichtig ist, hält ihre Priorität fest und verweist auf die Entscheidungen, die sie ausgelöst hat. Die arc42-Vorlage zum Beispiel verlangt auf der ersten Seite die drei bis fünf wichtigsten Qualitätsziele und später eine ausführlichere Liste von Qualitätsanforderungen. Die Liste wird immer dann überprüft, wenn eine große Entscheidung fällt oder das Unternehmen die Richtung ändert, und die wichtigsten Einträge werden schließlich durch automatisierte Prüfungen abgesichert, sogenannte Fitness Functions, die in Abschnitt 2.8 vorgestellt werden.