Trend 1: Vervollständigen Sie Ihre Systemanforderungen

Eine Frage, die in fast allen meinen Seminaren zum Thema Systemanforderungen auftaucht, ist: Wie können wir sicherstellen, dass unsere Anforderungsspezifikation vollständig ist? Das ist eine berechtigte Frage. Fehlende Anforderungen bedeuten in der Regel fehlende Fähigkeiten der Produkte, die wir entwickeln. Das hat Folgen für den Erfolg dieser Produkte. Entweder sind die Benutzer eines Produkts enttäuscht, weil sie etwas erwartet haben, das nicht geliefert wurde, oder das Produkt ist im Vergleich zu anderen Produkten mit ähnlichen Funktionen nicht wettbewerbsfähig genug.

Die Praxis zeigt, dass Anforderungsspezifikationen nur selten vollständig sind. Es ist nur sehr schwierig, sie vollständig zu machen und zu halten. Glücklicherweise haben wir in den letzten Jahrzehnten einige Techniken und Methoden gelernt, die uns bei unserem Streben nach Vollständigkeit helfen können.

Zunächst einmal funktionieren Vorlagen und Checklisten wirklich. Sie stammen aus den frühen Tagen der Technik und helfen uns, die offensichtlichen Anforderungen nicht zu vergessen. Heute gibt es Hilfe im Überfluss. Das Internet ist übersät mit Checklisten, die sich speziell auf Anforderungen beziehen.

Sie müssen auch selbst etwas nachforschen: Finden Sie alle Stakeholder, die einen potenziellen Einfluss auf den Erfolg des Produkts haben. Wenn Sie die Stakeholder vergessen, bedeutet das oft, dass Sie auch deren Bedürfnisse und Erwartungen an die Fähigkeiten des Produkts nicht erfassen werden. Das ist ein Rezept für Misserfolg. Natürlich müssen Sie Ihre Stakeholder befragen und herausfordern, um herauszufinden, was ihre wirklichen Bedürfnisse sind. Es hilft auch, diese Bedürfnisse explizit zu machen. Laden Sie nicht die Feuerwehr ein, wenn Sie einen neu gebauten Tunnel in Betrieb nehmen, nur um dann festzustellen, dass Sie möglicherweise einige wesentliche Sicherheitsmaßnahmen übersehen haben. Sie müssen die Feuerwehrleute schon in den frühen Phasen der Anforderungserhebung einbeziehen.

Stellen Sie sicher, dass Sie das zu entwickelnde Produkt aus verschiedenen Perspektiven betrachten. Betrachten Sie es mit den Augen der tatsächlichen Nutzer, Eigentümer und Investoren. Beziehen Sie die Interessengruppen ein, die auch die negativen Auswirkungen zu spüren bekommen. Diese Perspektiven lassen sich manchmal am besten in einem Betriebskonzept, User Stories, Anwendungsfällen und Szenarien beschreiben.

Machen Sie sich klar, dass der Schritt der Anforderungserhebung (bei dem Sie die Interessengruppen und ihre Bedürfnisse ermitteln) auf jeder Zerlegungsebene Ihrer Produktarchitektur für jedes Systemelement stattfindet! Auf jeder Ebene finden Sie neue Stakeholder, die für das jeweilige Systemelement auf dieser Ebene spezifisch sind. Denken Sie an Software-Codierungsstandards in einem multidisziplinären Produkt.

Analysieren Sie die Bedürfnisse auf strukturierte Weise. Das bedeutet, dass Sie zwischen der Hauptfunktion eines Produkts und seinen Unterfunktionen, zwischen einer Funktion, ihren Eigenschaften und ihren Designeinschränkungen unterscheiden müssen. Letztendlich müssen Sie ein Gleichgewicht zwischen den Anforderungen an die Leistung und die Ressourceneigenschaften der Funktionen finden.

Wenn wir einen Pkw als Beispiel nehmen und sagen, dass „Personen transportieren“ seine Hauptfunktion ist, müssen wir ausdrücken und quantifizieren, wie gut wir Personen transportieren müssen: wie komfortabel, wie zuverlässig, wie viele Personen, wie sicher? Dies sind Beispiele für Leistungseigenschaften (oder Qualitäten) einer Funktion. Sie werden mit den Ressourceneigenschaften abgeglichen, z. B.: wie viel Energie darf diese Leistung kosten, wie viel Materialkosten, wie viel Lärm? Während bei der Analyse die Funktionen, Eigenschaften und Einschränkungen identifiziert werden, werden bei der Anforderungsspezifikation die Eigenschaften quantifiziert.

Diese Methode ist Teil der strukturierten Anforderungsanalyse und eine der effektivsten Methoden, um die so genannten Emerging Properties zu entdecken – Eigenschaften, die von keinem Stakeholder gefordert wurden, aber einen spezifischen Produktaspekt darstellen, der sich aus den bei der Entwicklung getroffenen Entscheidungen ergibt. Wenn Sie sich zum Beispiel für einen Verbrennungsmotor entscheiden, ergeben sich als neue Eigenschaften die Geräuschentwicklung und die Emission giftiger Gase. Einige dieser neuen Eigenschaften können plötzlich sehr wichtig werden, nachdem sie lange Zeit außer Acht gelassen wurden, wie wir bei den NOx-Emissionen gesehen haben. Der Punkt ist, dass Sie, sobald eine Designentscheidung getroffen wurde, die Konsequenzen (gut, schlecht und hässlich) betrachten sollten, um zu sehen, ob neue Anforderungen geschaffen werden sollten, um die entstehenden Eigenschaften zu verwalten.

Im Laufe der Jahre haben sich die Namen der Produktentwicklungsabteilungen ziemlich verändert, insbesondere die der Gruppen, die für das Schreiben der Anforderungen auf Produkt- (oder System-) Ebene verantwortlich sind. Von der Produktdefinition über die Systementwicklung sehen wir jetzt Gruppen (manchmal Abteilungen), die so benannt sind, dass klar ist, wofür sie stehen, wie „Produkteigenschaften und Kundenfunktionen“. Auch der Titel von Hansjörg Maier von Porsche sagt alles: „Leiter Produkt-Eigenschaften und Kunden-Funktionen.“ Damit wird deutlich, worauf es bei dem Produkt ankommt, sowohl bei der Funktionalität als auch bei den Eigenschaften, und was das Produkt von der Konkurrenz abhebt.