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).

Geschrieben am

Externe Dokumente referenzieren — oder auch „Shooting on running targets“

79115

Shooting on running targets

Wenn eine Spezifikation externe Dokumente referenziert, dann ist es sehr einfach, in das Pattern „shooting on a runing target“ hineinzugeraten. Das bedeutet „Der Inhalt des Requirements ändert sich implizit, ohne dass ich ihn in irgendeiner Weise angefasst habe.

Das kann im wesentlichen aus zwei verschiedenen Gründen erfolgen:

  1. Das Requirement beschreibt eine Funktion in Abhängigkeit der Zeit — Beispiel: „Das System soll pro Jahr nicht länger ausfallen als die Anzahl seiner Benutzer in Stunden.“ Sprich: bei mehr Benutzern soll dem System auch mehr Downtime eingeräumt werden, bei weniger Benutzern weniger.
  2. Das Requirement bezieht sich auf ein weiteres, externes Dokument — Beispiel: „Das System soll die Eigenschaften erfüllen, die in Dokument X auf Seite 3 beschrieben sind.“ Hier kann es dazu kommen, dass das externe Dokument geändert wird und auf Seite 3 danach etwas völlig anderes steht. Das kann dazu führen, dass es unangenehme Nachfragen gibt beim Vertrieb des Produkts, in jedem Fall aber, dass an irgendeinem bestimmten Zeitpunkt nicht mehr klar ist, welche Eigenschaften das Produkt nun erfüllt.

Im vorliegenden Artikel geht es um den zweiten Fall.

Klassisches Beispiel ist die Referenzierung etwa

  • von Normen: „Das Produkt soll nach der EU-Barrierefreiheits-Richtlinie XYZ funktionieren.“;
  • von Schnittstellen: „Das Produkt soll die von System XYZ angebotenen Schnittstellen bedienen.“ oder
  • von Gesetzen: „Das Produkt soll nach § 4711 der Datenschutzrichtlinie funktionieren.“.

Allen diesen Möglichkeiten ist gemeinsam, dass ich als Requirements Manager nicht mitbekomme, wenn sich in dem externen Dokument was ändert.

Der erste Schritt ist, ein „shooting on a running target“-Requirement als solches zu erkennen. Der zweite ist dann, die Sache sauber zu machen. Folgende Möglichkeiten bieten sich an:

  • Copy & Paste: man kopiert sich 1:1 die Anforderungen aus dem externen Dokument in den Anhang des eigenen und schreibt, daß man explizit nur die kopierten erfüllen wird.
  • Einen festen Stand referenzieren: Man schreibt in die Biblography-Section des eigenen Dokuments eine feste Version (Stand) des externen Dokuments.

Die erste Möglichkeit ist evtl. die fehlersicherere, denn wenn man per Stand referenziert, ist man darauf angewiesen, daß man später den alten referenzierten Stand noch irgendwo auffindet. Man ist in der Nachweispflicht, daß man auch den alten Stand hat und kennt. Also muss man ihn sich sowieso irgendwohin sichern. Und wenn man das macht, dann muss man ihn nachher auch in den Weiten der eigenen Festplatte wiederfinden.

Geschrieben am

Verwechslungsgefahr — Projektanforderungen vs. Produktanforderungen

projektplan_speicher

Achtung Verwechslungsgefahr!

In meinen Trainingsveranstaltungen kommt immer wieder die Frage auf, warum es denn nicht sinnvoll ist, Projektaspekte  wie bspw.

  • Meilensteine,
  • Kosten,
  • benötigte Mitarbeiter oder
  • Deadlines

gleich zu Anfang des Projekts mit in das Lastenheft des Produkts hineinzunehmen. Gerne sogar als Anforderungen kenntlich gemacht.

Das Argument ist, dass der Leser dann alles direkt an einer Stelle vorfindet und auch die Brisanz des Ganzen direkt anhand der genannten Zeitabläufe und Kostenrahmen einzuschätzen lernt.

Ich spreche mich da immer aus den folgenden Gründen vehement dagegen aus: Verwechslungsgefahr — Projektanforderungen vs. Produktanforderungen weiterlesen