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

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!