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

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

Geschrieben am

Stakeholder — von guten und von pathologischen Vertretern ihrer Zunft

stakeholders

Stakeholder Management ist eine der spannendsten Disziplinen im Requirements Engineering. Wenn man es mal kurz und sarkastisch formulieren will, geht es um nichts anderes als herauszufinden, wen ich wie ernst nehmen muss von den zig Leuten, die mit mir (in meiner Rolle als Requirements Autor) reden wollen.

Bei vielen davon bin ich mir natürlich sicher, dass ich ihren Input in jedem Fall ernst nehmen muss. Bei anderen wiederum weiß ich, dass sie sich nur mit nett gemeinten Hinweisen an mich wenden.

Auch die umgekehrte Frage ist spannend: Welcher Stakeholder hat sich bei mir noch gar nicht gemeldet und ich muss aktiv auf ihn zugehen?

Wie für so vieles gibt es natürlich auch hier eine Norm, die uns bei der Suche nach den Stakeholdern weiterhilft, hier ist es die DIN ISO 100006, die folgendes dazu zu sagen hat:

Stakeholder eines Projektes sind alle Personen, die ein Interesse am Projekt haben oder von ihm in irgendeiner Weise betroffen sind.

Bin ich als Requirements Manager auf der Suche nach meinen Stakeholdern — also nach denjenigen Personen oder Parteien, denen ich Einfluss auf meine Spezifikationsdokumente geben möchte, dann wähle ich meist einen Ansatz nach diesen beiden Checklisten: Stakeholder — von guten und von pathologischen Vertretern ihrer Zunft weiterlesen

Geschrieben am

Willkommen!

Schön, dass Sie geklopft haben, kommen Sie doch rein!

Herzlich Willkommen zum Requirements Management Blog auf reinke.re und Schön, dass Sie hergefunden haben!

Ich möchte in diesem Blog Hinweise, Einschätzungen und Best Practices zum Thema Requirements Management geben und freue mich auf spannende Diskussionen mit Gleichgesinnten zu diesem Thema.

In diesem Blog wird es schwerpunktmäßig um Themen gehen wie

  • Requirements Management und Agiles Vorgehen;
  • Die Schnittmenge zwischen Requirements Management und Projektmanagement;
  • Die Abhängigkeiten zwischen Produktmanagement und Projektmanagement;
  • Fragen rund um die schriftliche Darstellung von Requirements.

Eine schöne Antwort auf die Frage „Was ist Requirements Management eigentlich?“ gibt das Buch von A. Stellman und J. Greene „Applied Software Project Management“. Hier wird Requirements Management über den Zweck definiert:

„The purpose of requirements management is to ensure that an organization documents, verifies, and meets the needs and expectations of its customers and internal or external stakeholders.“

— A. Stellman, J. Greene

Wer ich bin und was mich zum Thema Requirements Management verschlagen hat, können Sie auf der Seite Über mich nachlesen.

Viel Spaß und auf interessante Diskussionen!