Geschrieben am

„Das Produkt muss einen wertigen Eindruck machen“ — von Anforderungs-Esoterik Teil 4

five_elements

Den ersten Teil dieser Serie finden Sie hier, den zweiten hier und den dritten hier.

Pattern 7: „Mit langen Stangen im Nebel rühren“

Geschwurbelte Nebel-Anforderungen sind eigentlich die schönsten. Ich habe schon viele davon erlebt. Hier ein paar Beispiele:

„Der Komfort, mit dem Gerät zu arbeiten, soll vergleichbar sein mit einem Mobiltelefon.“

Oder auch

„Die Farbe des Produkts soll so beschaffen sein, dass der übliche Käufer damit zufrieden ist.“

Oder

„Die Reaktionszeit des Systems soll so schnell sein, dass der Benutzer nicht genervt ist.“

Oder schlussendlich auch der Name dieser Serie:

„Das Produkt muss einen wertigen Eindruck machen.“

Anforderungen wie diese lesen sich zunächst einmal recht flüssig. Wenn man nicht darauf achtet, liest man über sie auch schon einmal hinweg, weil sie eigentlich auf den ersten Blick schlüssig und klar erscheinen.

Erst auf den zweiten Blick haben diese Anforderungen ihre Probleme:

  • Ist Ihnen bspw. im ersten Requirement aufgefallen, dass Komfort nicht mit Komfort verglichen wird, sondern Komfort mit Mobiltelefon? Also Äpfel und Birnen?
  • Könnten Sie aus dem Stand die SI-Einheit benennen, in der man gängigerweise Komfort misst?
  • Haben Sie gemerkt, dass da nicht von „gleich“, sondern von „vergleichbar“ die Rede ist? Also wenn man Komfort in Einheiten messen könnte, würde das ausreichen — von „gleich komfortabel“ ist da nicht die Rede.
  • Haben Sie sich schon überlegt, mit welchem Mobiltelefon verglichen werden soll?

In der zweiten Anforderung oben wird die „Zufriedenheit des Käufers“ erwartet. Es bleibt unklar, wann der Käufer zufrieden ist und wer er überhaupt ist.

Probleme derselben Kategorie hat auch das dritte und vierte o.g. Requirement.

Allen Beispielen ist gemeinsam, dass ihre Erfülltheit nicht gemessen werden kann. Und das ist eine absolut notwendige Bedingung für Anforderungen:

Ist die Erfülltheit einer Anforderung nicht messbar, kann niemand sagen, ob das Produkt tut, was es soll.

Eine Anforderung muss entweder so geschrieben sein, dass sie direkt messbar ist — oder es ist notwendig, zu ihr ein Akzeptanzkriterium anzugeben. Das kann schon mal schwierig sein, gerade wenn es nicht um wissenschaftlich messbare Phänomene geht (Komfort, Zufriedenheit, Nerverei, Wertigkeit).

In den o.g. Fällen lässt sich das beabsichtigte z.B. durch eine Befragung von potentiellen Anwendern oder Käufern erreichen.

Ein Akzeptanzkriterium könnte dann etwa wie folgt lauten:

„Die Anforderung gilt als erfüllt, wenn von 50 befragten Käufern des Vorgängerprodukts mindestens 40 angeben, mit der Farbe zufrieden zu sein.“

Geschrieben am

„Das Produkt muss einen wertigen Eindruck machen“ — von Anforderungs-Esoterik Teil 3

Den ersten Teil dieser Serie finden Sie hier, den zweiten hier.

Pattern 5: „Schnee von gestern“

Anforderungen gehören nur dann in eine Spezifikation, wenn sie für das spezifizierte Produkt zeitlos gültig sind. Auch das kann man sehr einfach ohne fachlichen Hintergrund checken — es gibt zwei Kandidaten von Anforderungen, die bei diesem Check mit schöner Regelmäßigkeit auffallen und herausgesiebt werden können (oft nur mit zähem Diskutieren):

  • Projektanforderungen: Anforderungen, die eigentlich nur für das Projekt gelten, aber nicht für das Produkt, das in dem Projekt entwickelt worden ist. Also so Sachen wie „Die Entwicklung des Produkts soll am Ende nicht mehr gekostet haben als 200.000 €.“ oder „Das Entwicklungsteam soll mindestens zwei Tester enthalten.“ Beides ist für den Verlauf des Projekts interessant, danach kräht kein Hahn mehr danach. Näheres zu Projektanforderungen, die sich in eine Produktspezifikation verirrt haben, habe ich schon in einem eigenen Blog beschrieben, siehe hier.
  • Zeitlich beschränkte Produktanforderungen: Beispielsweise so etwas wie „Im Jahr der Auslieferung, also 2016, soll das Produkt mindestens 2 Millionen Datensätze verarbeiten können.“  — Da stellt sich die Frage: Nachher nicht mehr? Hier verbirgt sich meist eine nicht-funktionale Skalierbarkeitsanforderung, bei der der Autor nicht recht wußte, wie er sie formulieren sollte. Aber so wird das eben nichts.

Pattern 6: „Paragraphendeutsch“

Eine Anforderung muss eindeutig und klar verständlich sein für die gesamte Leserschaft sein. Viele Anforderungen leben in einem sehr technischen und hochspezialisierten Umfeld. Diese Umfelder neigen naturgemäß dazu, ihren eigenen Jargon zu haben — das ist völlig normal, denn ansonsten wäre eine Kommunikation zeitaufwändig.

Bei Spezifikationen kann es jedoch jederzeit dazu kommen, dass sie von Personen gelesen werden (müssen), die nicht direkt diesem Umfeld entstammen. Sei es, weil der neue Kollege eingearbeitet werden muss, sei es, dass Teile doch an einen Dienstleister übergeben werden.

Wenn Spezifikationen dann völlig kryptisch sind, geht es nicht weiter und das Projekt bekommt Sand ins Getriebe.

Es gibt einige Dinge, die man überprüfen kann:

  • Kommen Fachwörter in den Spezifikationen vor, die Leser, die ausschließlich über normales Branchenwissen verfügen, nicht verstehen würden? Wenn ja, dann empfiehlt es sich, darauf zu verzichten oder ein Glossar anzulegen und die Fachwörter dort zu erklären.
  • Wird eine Domain Specific Language (DSL) zur Spezifikation verwendet? Auch hier ist eine Referenz auf ihre Definition unerlässlich.
  • Sind die Sätze lang, verschachtelt und schwierig zu lesen? Dann muss was geändert werden, denn niemand hat Lust, durch solches Wirrwarr durchzusteigen. Mit der Konsequenz, dass die Spezifikation nicht korrekt umgesetzt wird.

 

 

Geschrieben am

„Lass uns ein Meeting machen!“

conference-table-24030335

„Lass uns ein Meeting machen!“

Aus aktuellem Anlass unterbreche ich mal die Serie über die esoterischen Anforderungen und schiebe mal einen Rant über die Meeting-Unkultur im Bereich Requirements Management ein. Wie üblich, muss Paul für die Einleitung herhalten:

Product Owner Paul kommt kurz nach Sprintanfang gut gelaunt über den Flur. Seine Tasse mit heißem Kaffee duftet verführerisch. Gestern das Sprint Planning lief super. Er freut sich darauf, heute mal Dinge nacharbeiten zu können, die in den letzten paar Tagen wegen der Vorbereitungen auf das Sprint Planning liegen bleiben mussten.

Leider kommt er nicht weit.

Als er an Scrum Master Simons Büro vorbeikommt, kommt ihm ein hektischer Simon entgegen gesprungen:

„Wir haben ein Problem mit den Anforderungen. Wir wollten heute mit dem Top Prio Sprint Backlog Item anfangen. Aber wir haben da im Sprint Planning völlig was übersehen! Keine Ahnung, wie das passieren konnte! Aber so wie wir uns das gedacht haben, funktioniert das hinten und vorne nicht! Was sollen wir tun?“

„Ok, wir müssen das lösen. Lass uns ein Meeting machen!“

„Ok, wer lädt ein?“

„Du.“

„Ok. Wer soll alles mit dazu?“

„Weiß nicht. Am besten einfach alle. Jetzt gleich. Blocke uns 4 Stunden.“

Es kommt, wie es kommen muss: Von den 24 Personen sagen 20 Personen 4 Stunden lang so gut wie gar nichts. Die übrigen 4 Personen reden teilweise über technische Lösungen, prozessuale Lösungen, Umgehungen, die Schuldfrage und grundsätzliche Erwägungen, um nie mehr in eine solche Situation zu kommen. Das Fazit am Ende der 4 Stunden:

  • Mehrere Lösungsmöglichkeiten, keine Entscheidung für oder gegen eine davon.
  • Folglich keine vergebenen Arbeitsaufträge.
  • Keine Entscheidung über das weitere Vorgehen zur Lösungsfindung.
  • 24 × 4 h = 96 h vertane Zeit. Bei einem ungefähren internen Stundensatz von 50 € also ca. 5.000 €.

Was ist schief gelaufen?

„Lass uns ein Meeting machen!“ weiterlesen

Geschrieben am

„Das Produkt muss einen wertigen Eindruck machen“ — von Anforderungs-Esoterik Teil 2

five_elements

„Das Produkt muss einen wertigen Eindruck machen“ — von Anforderungs-Esoterik Teil 2

Den ersten Teil dieser Serie lesen Sie hier.

Pattern 3: „Widersprüche“

Auch auf Widersprüche lässt sich eine Spezifikation einfach überprüfen. Eine Anforderung sollte sich nicht selbst widersprechen — und es sollte auch keine anderen Anforderungen geben, die ihr widersprechen. Auch hier wieder ein Beispiel:

Das System soll jegliche Aktion verweigern, wenn der Benutzer nicht mindestens die Benutzerrechte X und Y hat.

[..]

Das System soll es jedem Benutzer ermöglichen, die Systemaktion „Logfile anschauen“ auszuführen.

Der Sinn dieses Patterns erschließt sich von selbst. Wenn das System widersprüchlich definiert ist, zeugt das von einer schlechten Anforderungserfassung beim Kunden — oder auf tieferen technischen Ebenen auf einem unvollständigen Verständnis der darüber liegenden fachlichen Anforderungen. Die Umsetzung leidet dadurch und es kann zu unerwartetem Systemverhalten kommen, jenachdem in welcher Situation das System ist.

Pattern 4: „Woher kommt das?“

Auch auf dieses Pattern kann ich sehr gut prüfen, ohne ein tieferes fachliches Verständnis des konzipierten Produkts zu haben. Es geht hier um die sogenannte Traceability: Für jede Anforderung muss nachvollziehbar sein, woher sie kommt.

Auf fachlicher Ebene kann dies über eine an der Anforderung genannte Rationale kenntlich gemacht werden (die wiederum auf Dokumentation von Kundengesprächen oder -interview verweist), auf technischer Ebene durch eine  Bezugnahme auf das zugrunde liegende fachliche Problem — bzw. die zugrunde liegende fachliche Anforderung.

Finde ich ein solches Tracing nicht vor, dann haben sich entweder Anforderungen eingeschlichen, die eigentlich out of scope sind und Geld kosten, das eigentlich niemand bezahlen möchte — oder es wurde einfach das Tracing vergessen.

Ein vollständiges Tracing ist nicht einfach nur art pour l’art — es hat den Sinn, drei Fragen sofort beantworten zu können:

  1. Welche technischen Anforderungen werde nicht mehr benötigt, wenn eine bestimmte Kundenanforderung (Teil der Problembeschreibung) wegfällt?
  2. Welche Kundenanforderung wird nicht mehr erfüllt, wenn man eine bestimmte technische Anforderung (Teil der Lösung) weglässt oder modifiziert — bspw. weil sie zu teuer ist?
  3. Lässt sich eine bestimmte technische Anforderung eventuell ersetzen durch eine andere — und zwar so, dass der zugrunde liegende Kundenwunsch immer noch erfüllt ist?

Alles drei sind wertvolle Informationen, auf die man nicht ohne Not verzichten sollte.

 

Geschrieben am

„Das Produkt muss einen wertigen Eindruck machen“ — von Anforderungs-Esoterik Teil 1

five_elements

„Das Produkt muss einen wertigen Eindruck machen“ — von Anforderungs-Esoterik Teil 1

Wenn ich gebeten werde, Anforderungen zu reviewen und ich die Branche fachlich nicht kenne, habe ich nur zwei Möglichkeiten, Spezifikationen auf ihre Qualität hin zu untersuchen:

  1. Ich lasse mir das spezifizierte Produkt erklären — das geht nur eingeschränkt, weil dazu andere Leute viel Zeit opfern müssen und ich ein volles Branchenverständnis selbstverständlich in kurzer Zeit nicht aneignen kann; oder
  2. Ich schaue mir an, ob die Anforderungen, die ich vorfinde, formal sauber sind — das geht schon wesentlich besser, denn das kann ich alleine und ohne jede Zuarbeit erledigen.

Für letzteres möchte ich hier mal ein paar Kriterien zum Besten geben.

Am meisten Spaß macht das natürlich anhand von Beispielen. Ich habe also mal tief in die Historie geschaut.

Pattern 1: „Zwei auf einen Streich“

Das System muss American Express-Kreditkarten und Paypal als Zahlungsmittel akzeptieren.

Die Anforderung klingt erst einmal völlig in Ordnung. Jeder weiß, was damit gemeint ist, Entwickler wissen, welche APIs sie verwenden müssen, es sollte doch alles paletti sein. Das Problem liegt hier im Wörtchen „und“, denn hier handelt es sich um zwei Anforderungen versteckt in einer. Die Implementierung der einen Zahlweise ist ja völlig unabhängig von der Implementierung der anderen.

Nun sollte man meinen, dass das ja nicht weiter schlimm ist, denn schließlich werden ja beide Anforderungen umgesetzt und ob sie dann nun in einem Satz stehen oder in zwei Sätzen, kann doch egal sein.

Für die Entwicklung stimmt das auch.

Allerdings wird es spätestens im Test schwierig, weil es vielleicht keine disjunkten Tests für die Kreditkartenzahlung und die Paypal-Zahlung gibt. Das bedeutet dann auch, dass ein Report darüber, welche Anforderungen bereits erfolgreich umgesetzt sind, hier keine Antwort liefert.

Und dann kann es zur folgenden unglücklichen Situation kommen:

Der Kunde ruft an und sagt, er wüsste gerne den Stand der bisher umgesetzten Features, denn er braucht das Feature „Paypal-Zahlung“ bereits früher als geplant und würde ein Vorziehen des nächsten Releases wünschen. Ob denn die Paypal-Zahlung bereits funktioniert. Der Projektleiter beim Auftragnehmer kann ihm diese Frage nicht beantworten (er sieht nur, das Requirement ist im Report auf rot – aber das kann heißen, dass Paypal funktioniert und die Kreditkarte nicht). Und wie es so kommt, sind alle diejenigen gerade nicht greifbar, die die Information haben.

Es gibt einen weiteren Nachteil: Wenn Entwicklungsabteilungen eine erste grobe Aufwandsschätzung bspw. standardisiert nach Function Point Verfahren durchführen, kommen trügerisch geringe Aufwandsabschätzungen heraus, sobald man mehrere Dinge in einer einzigen Anforderung unterbringt. Wenn auf einer Function Point-Schätzung dem Kunden gegenüber grobe erste Schätzungen kommuniziert werden, kommt man in die missliche Lage, die genauere Schätzung deutlich nach oben korrigieren zu müssen. Der Unmut des Sales Personals ist einem gewiss.

Pattern 2: „Es fehlt was“

Das Problem hier ist schwieriger auszumachen und es ist auch meistens ohne fachliche Expertise schwierig feststellbar, ob in einer Spezifikation etwas fehlt. Ein Hinweis, auf den ich rein formell einfach prüfen kann, ist, nach bedingten Anforderungen zu suchen:

Wenn das Ventil B geschlossen ist und eine Verbindung zwischen Komponente K und L besteht, die Spannung an Abtastpunkt A nicht größer ist als 0,5 V oder an Abtastpunkt B größer als 0,7 V ist, dann soll das System Verbindung zu Steuereinheit S aufbauen.

In dieser Anforderung ist eine komplexe Bedingung vorgeschaltet. Wenn sie erfüllt ist, sollen bestimmte Dinge passieren.

Die offene Frage ist: Was, wenn die Bedingung nicht erfüllt ist? Soll dann einfach gar nichts passieren? Oder soll etwas anderes passieren?

Nach solchen bedingten Anforderungen lässt sich suchen ohne jegliche tiefere fachliche Kenntnis des beschriebenen Produkts. An jeder einzelnen von ihnen ist die Frage legitim: Was soll sonst passieren? Warum steht das da nicht?

 

Weiter geht’s in Teil 2.

Geschrieben am

Von selbst passiert nichts – oder: wie bekomme ich als Anforderungsautor Antworten?

frage-und-antwort

Wie bekommt man als Spezifikateur Input?

In Requirements Management Trainings bekomme ich regelmäßig die Frage:

„Ich habe einige wichtige Stakeholder um ihren Input gebeten — aber die rühren sich einfach nicht! Wie kriege ich die dazu, mir endlich ihren Input zu geben?“

So einfach das Thema klingt, so leichtfertig sollte es nicht genommen werden.

Wenn Spezifikationsautoren ihren Input nicht bekommen, weil sie nicht wissen, wie sie ihn aus den nicht antwortenden Stakeholdern „herausbekommen“, dann ist das nicht auf die leichte Schulter zu nehmen. Fehlender Input bedeutet fehlende Anforderungen – und Anforderungen, die man nicht kennt, kann man nicht erfüllen.

Hin und wieder gibt es Ansätze wie etwa die folgenden:

„Es müsste da eine firmeninterne Anweisung geben, dass jeder auf Fragen eines Spezifikateurs antworten muss!“

Oder auch

„Wenn ich keinen Input bekomme, dann denke ich mir selbst was aus, was zum befragten Stakeholder eigentlich passen müsste — und hoffe, dass es stimmt. Ich versuche, das dann aber vor dem nicht antwortenden Stakeholder zu verbergen, nachher merkt der das und dann dauert es noch länger!“

Und dieses Statement habe ich auch bereits mehr als einmal gehört:

„Der Stakeholder, der mir nicht antwortet, ist mein Chef. Den kann ich ja schon prinzipiell nicht unter Druck setzen und zwingen zu reagieren!“

Es gibt jedoch eine Reihe von sehr freundlichen Maßnahmen, die es ermöglichen, als Spezfikateur in solchen Situationen durchaus guten und zeitnahen Input zu bekommen — oder die Information, dass es von Stakeholderseite nichts Nenneswertes einzubringen gibt. Was ja auch ein akzeptabler Input ist.

Der Kerngedanke aller folgenden Überlegungen ist der folgende:

Druck oder „Dienstanweisungen“ funktionieren nicht — Das Skizzieren von Konsequenzen aber durchaus

Von selbst passiert nichts – oder: wie bekomme ich als Anforderungsautor Antworten? weiterlesen

Geschrieben am

„Wir arbeiten agil und brauchen daher keine Spezifikation“

Unbenannt

Machen wir uns nichts vor

In „klassischen“ Projektvorgehensweisen, etwa nach dem Wasserfall- oder dem V-Modell wird viel Papier erzeugt und jede Menge an Spezifikationen geschrieben, die sich im späteren Verlauf als nicht haltbar herausstellen. Viel Mühe — und meist völlig umsonst.

Agiles Vorgehen im Projekt geht dieses Problem folgendermaßen an.

  1. Kurzer zeitlicher Abstand zwischen Konzeption und Umsetzung: Die Zeit von der genauen Konzeption eines Inkrements bis zur Umsetzung erfolgt im Scrum-Prozess im Sprint Planning Meeting. Zwischen dem Sprint Planning Meeting und dem Sprint selbst vergeht nicht viel Zeit, so lange kann man sich auch komplexere Dinge meist einfach merken.
  2. Der Product Owner ist involviert: Der Product Owner — also der Kunde selbst oder sein in-house Vertreter — ist bei der Konzeption eng mit dabei und nicht nur ein Jahr im Voraus in der Spezifikationsphase wie im klassischen Wasserfall- oder V-Modell-Vorgehen.
  3. Das Entwicklungs-Team ist involviert: Die Entwickler sind bei der Konzeption involviert, wissen also auch, was entschieden und vereinbart worden ist — und lesen es nicht erst lange später „aus zweiter Hand“ nach.
  4. Die Abnahme liegt ja von der Konzeption nur einen Sprint „entfernt“: Das bedeutet, auch zum Zeitpunkt der Abnahme wissen noch alle, was vereinbart war. Im Original-Scrum-Prozess sind das nur wenige Wochen.

Diese vier Regeln sorgen dafür, dass zu Beginn jedes einzelnen Sprints bei allen Beteiligten ein sehr hohes Verständnis und ein hoher Konsens darüber besteht, was im Sprint entwickelt wird und wie es genau entwickelt wird.

Dann besteht doch eigentlich keine Notwendigkeit, das alles minutiös aufzuschreiben — oder?

Sollte man meinen. Oder?

Es gibt aber einige Aspekte, die auch in einem agilen Projektvorgehen für Spezifikationen sprechen.

„Wir arbeiten agil und brauchen daher keine Spezifikation“ weiterlesen

Geschrieben am

Requirements Management in Word — geht das?

word

Requirements Management in der Textverarbeitung

In Requirements Management Trainings kommt es nicht selten vor, dass ein Teilnehmer in die Runde fragt

„Entschuldigung, wenn ich das einfach mal so ungeniert frage, aber: Welches Tool nehmt ihr denn eigentlich alle so zum Requirements Management?“

Dann kommen ein paar Antworten („Enterprise Architect“, „Etwas selbst gebautes“, „Doors“) und einige schauen ganz sparsam auf ihre Fingerspitzen und sagen erst auf Nachfrage ganz leise und verschämt:

„Wir nehmen Word…“

Ich finde, ein Textverarbeitungsprogramm (ob es nun Microsoft Word ist oder Open Office oder Google Docs) ist als Requirements Management Werkzeug unter einigen Voraussetzungen gar nicht so verkehrt. Die Voraussetzungen möchte ich hier einmal etwas genauer betrachten: Requirements Management in Word — geht das? weiterlesen

Geschrieben am

Welches Requirements-Management-Tool? — Die Qual der Wahl

Toolbox with tools on white isolated background. 3d

Welches Tool — die Qual der Wahl

Im Anschluss an Requirement-Management-Trainings kommt immer wieder die Frage auf, welches Requirement Management-Tool denn das beste sei.

Meine Antwort darauf ist: Es gibt nicht das beste Tool. Verschiedene Tools können unterschiedliche Dinge gut und je nach Preis können sie vielleicht sogar viele Dinge gut. Vielleicht sogar welche, die man gar nicht braucht und eigentlich nicht bezahlen möchte.

Wer sich für die Einführung eines Requirements-Management-Tools interessiert, hat leider zunächst einmal die zeitintensive Aufgabe, sich genau zu überlegen, was er damit machen möchte — und was nicht. Dies ist von Organisation zu Organisation verschieden, stark vom Reifegrad des Spezifikationsprozesses abhängig, weiterhin natürlich stark abhängig von der Art des Produkts — sowie von vielem mehr.

Ich will im folgenden verschiedene Kriterien nennen, die Organisationen durchgehen sollten, die vor der Entscheidung stehen, ein Requirements-Management-Tool zu verwenden: Welches Requirements-Management-Tool? — Die Qual der Wahl weiterlesen

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