Geschrieben am

Anforderungen — und wie man sie formuliert

beurteilung

Anforderungen — und wie man sie formuliet

Folgende Anforderung fand ich in einem Lastenheft, das ich neulich reviewen sollte:

„The communication protocol between the device D and the system S shall make use of checksums in order to prevent data from being changed during transmission from D to S.“

An dieser Anforderung sind mehrere Dinge problematisch:

  1. Für ein Lastenheft ist diese Beschreibung viel „zu tief“. Hier wäre alleine die Anforderung sinnvoll, daß gewährleistet werden muss, dass Daten unterwegs nicht verfälscht werden können. Der Teil „durch eine Checksumme“ ist eine Lösungsbeschreibung (und nebenbei sogar eine denkbar schlechte, denn ein Angreifer kann eine gewöhnliche Prüfsumme im Gegensatz zu einem MAC einfach ebenfalls fälschen). Eine Lösungsbeschreibung hat in einem Lastenheft aber nichts verloren.
  2. Rein fachlich ist die Erfüllung dieser Anforderung unmöglich: Daten können, wenn sie übertragen werden, immer verfälscht werden. Das ist nicht zu verhindern. Aber: es ist möglich, dies zu erkennen und die Daten beim Empfänger dann zu verwerfen. Eine Anforderung sollte sich also darauf beschränken.
  3. Diese Anforderung enthält ein „in order to“ — einen Zweck. Das bedeutet, wenn man es genau nimmt, dass ein Tester nicht nur sicherstellen muss, dass die Anforderung erfüllt ist, sondern auch, dass sie aus diesem Grund (dem Zweck) erfüllt ist. Das ist natürlich unmöglich und auch nicht beabsichtigt.
  4. Die Beschreibung des Zwecks an sich ist sinnvoll, macht aber die Anforderung selbst unnötig lang und jeder, der diese Anforderung weiter verarbeiten muss, muss unnötig viel lesen. Das sorgt für Mißverständnisse. Wenn zu einer Anforderung noch ihr Sinn und Zweck hinterlegt werden soll (was ich sehr empfehle), dann geschieht dies am besten in einer Notiz darunter.
  5. Man kann darüber hinaus auch das Wording „communication protocol“ eigentlich weglassen, denn alles, was danach passiert, bezieht eine Lösung genau auf diese logische Komponente. Eine „Komponentisierung“ des Systems und eine darauf basierende Zuweisung, welche Komponente gefälligst welche Anforderung erfüllen soll, ist aber weit außerhalb des Auftrags für ein Lastenheft — es reicht ja schließlich auch völlig aus, wenn das Gesamtsystem die Anforderung erfüllt. Dem Kunden ist es egal, ob die Sicherheit der Übertragung durch das Protokoll der Verbindung oder durch andere Mechanismen erzielt wird.

Hier ein Vorschlag, wie man die obige Anforderung besser formulieren könnte:

„The system shall make sure that data which has been altered during transmission between device D and system S is recognized upon arrival and discarded.“

Die Beschreibung des Zwecks entfällt jetzt sogar. Und es ist jetzt möglich, sehr unterschiedliche Lösungen für diese Anforderung zu entwerfen – und zwar ohne eine Änderung des Lastenhefts anzuleiern (was meist die Zustimmung von 10 Personen erfordert, von denen 12 in Urlaub und 14 weitere auf Dienstreise sind).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.