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!