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:

  1. Kosten, Zeitrahmen und ähnliches sind keine Anforderungen, die das Produkt/System erfüllt — sondern das Projekt. Zudem sind diese Dinge nicht testbar (wohingegen der Anspruch eigentlich ist, dass alle Produktanforderungen getestet werden sollten). Diese Aspekte als Anforderungen zu nennen, macht also schon mal überhaupt keinen Sinn.
  2. Darüber hinaus empfehle ich aber auch nicht, diese Aspekte überhaupt in ein Anforderungsdokument hineinzunehmen, denn
    • zum einen sind sie von Natur aus sehr dynamisch,
    • des weiteren gibt es für sie eigentlich das Dokument „Projektplan“ und
    • zum dritten möchte man eigentlich keinen erneuten (möglicherweise schwerfälligen) Freigabeprozess für das Lastenheft durchlaufen, nur weil nicht mehr Herr Meyer, sondern Frau Müller mitarbeitet oder die Deadline vom 01.08. auf dem 01.09. verschoben wurde.
  3. Es gibt noch einen weiteren Aspekt:
    • Projektanforderungen sind — im Gegensatz zu Produktanforderungen — nach Projektende kaum noch gefragt. Es kann sein, dass irgendeine an Projektstatistiken interessierte Abteilung Auswertungen darauf fährt, aber ansonsten ist das Interesse an Projektanforderungen eher nur historisch/archäologischer Natur.
    • Produktanforderungen hingegen bestehen fort. Das Produkt muss diese ja nicht nur während des Projekts erfüllen, sondern auch danach. Außerdem muss es ja möglich sein, Produktverhalten daraufhin zu untersuchen, ob ein Produktfehler vorliegt.

Daher empfehle ich, ein Anforderungsdokument nicht mit Dingen zu überfrachten, die eigentlich nur den Projektrahmen definieren — aber nicht das Produkt.

Schreibe einen Kommentar

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