Und täglich grüßt das Pflichtenheft

Wenn ich mit einem Blog Artikel über die Entwicklung starte, dann mit dem Thema Pflichtenheft. Denn das Pflichtenheft ist das Fundament einer jeden Entwicklung. Das Pflichtenheft hat Auswirkungen auf die Architektur, die technische Realisierung, die Projektkosten, den Terminplan, die Herstellkosten, den Lieferumfang und nicht zuletzt die Kundenzufriedenheit und den Markterfolg. Es ist somit eines der wichtigsten Dokumente im Projekt überhaupt. Gerade deshalb ist es wichtig, dass das Fundament stabil ist. Sonst gerät das Projekt von vornherein in Schieflage.

Projekte scheitern oft am Requirements-Engineering und daher möchte ich auf das wichtige Thema eingehen. Stellt sich die Frage was unter Requirements-Engineering überhaupt zu verstehen ist? Darunter versteht man den geordneten Prozess in dem Anforderungen ermittelt, dokumentiert, verwaltet, analysiert, abgestimmt und geprüft werden. Damit ergeben sich aus Bedürfnissen, Visionen und Randbedingungen, Anforderungen an ein Projekt und an ein Produkt.

req_eng1

Bei der Frage, was eine Anforderung ist hilft IEEE 1990 weiter:

  • Eine Eigenschaft oder Bedingung, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
  • Eine Eigenschaft oder Bedingung, die ein System oder eine Systemkomponente erfüllen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere formell vorgegebene Dokumente zu erfüllen.

Diese doch sehr formale Beschreibung kann man bildlich auch mit der DNA des Systems vergleichen. Ein nicht umsichtiger Umgang mit Anforderungen kann zu großen Schäden führen.

Der Aufwand beim Schreiben eines Pflichtenheftes steckt nicht im Schreiben selbst, sonst wäre man nach spätestens einer Woche fertig, wenn man halbwegs tippen kann. Der größte Teil der Arbeit ist Kommunikation. Dabei gilt es verschiedene Stakeholder ins Boot zu holen und deren oft widersprüchlichen Anforderungen einzusammeln und abzugleichen. Aus meiner Erfahrung steckt hier ca. 2/3 der Arbeit. Die Stakeholder können dabei der Produktmanager, Kunde, Auftraggeber, Projektmanager, Management, QM/RA, Service, Produktion, Juristen und viele mehr sein.

Beim Schreiben der Anforderungen gibt es einiges zu beachten. Ich nenne das auch die Anforderungen an die Anforderungen. Darunter verstehe ich Eigenschaften, die eine Anforderung aufweisen soll.

anfananf

EigenschaftErklärung
TestbarJede Anforderung wird abgeprüft. Wenn Ihnen kein sinnvoller Testfall einfällt, dann ist die Anforderung nicht gut.
VollständigAchten Sie darauf nichts zu vergessen. Viele Informationen hat man im Kopf. Bringen Sie diese auch zu Papier. Entsprechend wird auch die Testtiefe verbessert.
RelevantFormulieren Sie nur Anforderungen, die für die Komponente oder das System relevant sind. Es ist nicht relevant welche Bauteile Sie einsetzen oder wie die Umsetzung konkret aussieht.
KonsistentVermeiden Sie Widersprüche bei den Anforderungen. Achten Sie darauf, dass die Anforderungen zusammen passen.
EindeutigFormulieren Sie die Anforderungen eindeutig, so dass sich kein Raum für Interpretation ergibt.
KontextfreiFormulieren Sie die Anforderung so, dass man sie ohne den Kontext versteht. Schlecht ist z.B. wenn man die Anforderung nur versteht, wenn man weiß in welchem Kapitel sie steht. Die Anforderung soll allein für sich verständlich sein.
AtomarHalten Sie die Anforderung kurz und knapp. Versuchen Sie nicht mehrere Anforderungen in eine unter zu bringen. Damit werden die Anforderungen verständlicher, lesbarer und leichter testbar.

Bei der Formulierung der Anforderungen kann man viel falsch machen. Idealerweise setzt man Satzschablonen ein, die die Qualität der Anforderungen deutlich erhöhen. Dabei baut man die Anforderungen immer nach dem gleichen Schema auf. Das kann zwar bei der Erstellung langweilig sein, ist aber für die Verständlichkeit und Klarheit ein großer Gewinn.

satzschablone

Aus meiner Erfahrung in Projekten habe ich eine Liste mit 10 Tipps zusammengestellt, die oft nicht berücksichtigt oder bedacht werden.

  1. Jede Anforderung hat ein Preisschild und kostet Geld.
  2. Jede Anforderung kostet Zeit.
  3. Vergessen Sie nie die Zweckbestimmung des Gerätes in der Medizintechnik.
  4. Verwenden Sie ein Glossar mit eindeutigen und definierten Begriffen.
  5. Führen Sie mit dem Kunden oder den Stakeholdern Workshops durch und machen Sie kein Pingpong-Spiel.
  6. Weniger ist mehr. Hinterfragen Sie jedes Feature kritisch.
  7. Behalten Sie den Kundennutzen im Fokus. Der Kundennutzen ist der Grund, dass das Produkt gekauft wird.
  8. Schieben Sie Entscheidungen nicht auf die lange Bank. Nicht getroffene Entscheidungen können dazu führen, dass viel Energie unnötig investiert wird.
  9. Definieren Sie welche Priorität eine Anforderung hat, was umgesetzt werden muss und was optional ist.
  10. Vermeiden Sie implizite Annahmen. Das Pflichtenheft sollte auch verstanden werden, wenn man kein Vorwissen hat.

Ich habe oft in Projekten gehört: “Unser Kunde / unser Produktmanager weiß nicht was er will!”. Mittlerweile habe ich herausgefunden, dass das nicht die Ausnahme sondern die Regel ist. Wir entwickeln innovative Produkte, wo eben nicht alles bekannt ist. Zudem verändert sich die Welt und damit die Anforderungen an das Produkt. Pro Monat ändern sich ca. 1-5% der Anforderungen! Dagegen hilft es nur, die Projekte kurz zu halten, den Aufwand und die Komplexität zu reduzieren und frühzeitig ein Änderungsmanagement aufzusetzen. Wenn Sie mit Anforderungen arbeiten, dann benötigen Sie auch ein Werkzeug dafür. Bitte nutzen Sie dafür nicht Word und Excel! Das funktioniert bei größeren Projekten nicht mehr. Darauf komme ich in einem der folgenden Blog Artikel noch mal zu sprechen.

Ein wichtiger Tipp noch zum Schluss. Führen Sie Reviews durch und prüfen Sie das Pflichtenheft formal, inhaltlich und wirtschaftlich. Nehmen Sie dazu Ihre wichtigen Stakeholder mit ins Boot. Es kann auch sinnvoll sein, kleine Teilabschnitte zu reviewen. Das führt zu schnellen Ergebnissen.

Fehler, die man im Pflichtenheft macht, begleiten einen jeden Tag im Projekt. Achten Sie daher bei der Erstellung darauf, damit das Pflichtenheft nicht zu Ihrem täglichen Wahnsinn wird.

Ich freue mich über Feedback und wenn Sie mit mir in Kontakt treten. Sie können gerne auch einen Kommentar zu dem Artikel abgeben. Falls Sie jemanden kennen, für den der Blog ebenfalls interessant sein könnte, freue ich mich auch sehr über eine Weiterempfehlung.

Viele Grüße

Goran Madzar

Auch interessant:

Integrationsplanung – Mehr als Big Bang

Die Aufgabe des Systemarchitekten ist es ein System in einfachere Subsysteme zu zerlegen. Die Subsysteme werden dann zunächst getrennt voneinander entwickelt und später wieder zusammengeführt. Diese Zusammenführung wird Integration genannt.…

Goran Madzar

Seit Mai 2007 bin ich zusammen mit meinem Kollegen Martin Bosch selbständig. Wir haben ein Ingenieurbüro im Innovations- und Gründerzentrum in Erlangen aufgebaut. Hier entwickeln wir für Kunden in der Medizintechnik mit unseren Mitarbeitern Lösungen für die Produkte von Morgen.

Getagged mit: , , ,
0 Kommentare zu “Und täglich grüßt das Pflichtenheft
    1 Pings/Trackbacks für "Und täglich grüßt das Pflichtenheft"

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht.