Um Software entwickeln zu können, müssen die Anforderungen an die Software bekannt sein. Sinn und Zweck des Requirements Engineerings ist es unter anderem, diese Anforderungen zu erfassen und zu validieren. Solche Schritte sind aber nur in Zusammenarbeit mit den für die Software relevanten Stakeholdern möglich. Daher steht am Anfang des Requirements-Engineering-Prozesses typischerweise die Stakeholder-Analyse, also die Bestimmung aller relevanten Stakeholder und deren Beziehungen untereinander.
Das International Requirements Engineering Board (IREB) definiert in Basiswissen Requirements Engineering Stakeholder dabei als „[…] eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.“ Die Beispiele, die auf solch eine Definition folgen, sind typischerweise immer dieselben: End-User, das Management, aber auch juristische Personen und Gesetze etc. Dabei werden jedoch oftmals Software-Entwickler:innen als Stakeholder des Systems ausser Acht gelassen. Im Folgenden werden einige Gründe genannt, warum Software-Entwickler:innen nicht nur als reine Umsetzer von Anforderungen, sondern ebenfalls als Stakeholder im Anforderungsprozess anerkannt und berücksichtigt werden sollten.
Technischer Hintergrund
Der sicher offensichtlichste Grund für den Stakeholder-Status von Entwickler:innen ist die Tatsache, dass sie unmittelbar Einfluss auf die Eigenschaften und den Zustand der Software haben. Dazu zählt zum einen das technische Know-how, welches die Umsetzung des Systems auf technischer Ebene einschränkt. Entwickler:innen können fachliche Anforderungen nur im Rahmen ihrer eigenen technischen Fähigkeiten umsetzen. Neben den Fähigkeiten zählen dazu aber auch persönliche Präferenzen der jeweiligen Entwickler:in für Programmiersprachen, Frameworks, Bibliotheken etc. Hinzu kommt, dass diese Entwickler-Entscheidungen Einfluss auf spätere Anforderungen haben können. So kann eine frühe Architektur-Entscheidung beeinflussen, wie oder sogar ob eine spätere Anforderung umgesetzt werden kann.
Im Folgenden werden noch zwei weniger offensichtliche Gründe genannt, warum Entwickler:innen als Stakeholder zu betrachten sind. Genauer jedoch nicht als Stakeholder, sondern als Meta-Stakeholder. Meta-Stakeholder bezeichnet dabei eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf den Anforderungsprozess hat oder davon betroffen ist. Im Gegensatz zu Stakeholdern geht es dabei also nicht um Anforderungen gegenüber dem System, sondern Meta-Anforderungen gegenüber der Erfassung und insbesondere Dokumentation von Anforderungen an das System.
Grad der Formalität
Spezifikationen unterscheiden sich oftmals stark dahingehend, wie technisch sie sind. Die Bandbreite reicht dabei von knappen und rein fachlich formulierten Anforderungen auf Post-its bis hin zu seitenlangen Dokumenten in formalen Sprachen. Dabei wird manchmal auch sogenannter Pseudocode verwendet, also bereits programmatische Anweisungen an ein System – jedoch in natürlicher Sprache statt in einer Programmiersprache formuliert.
Wie technisch und wie detailliert eine Anforderung zu formulieren ist, hängt dabei auch von den jeweiligen Entwickler:innen ab, die am Ende mit der Spezifikation arbeiten und sie umsetzen sollen. So benötigen unerfahrenere Entwickler:innen oftmals eine eher techniknahe Spezifikation, um sie entsprechend umsetzen zu können. Erfahrene Entwickler:innen hingegen bestehen oftmals darauf, dass nur die fachlichen Anforderungen vorgegeben werden sollen. Die Aufgabe der Umsetzung in programmatischen Schritten wollen sie sich nicht nehmen lassen.
Fachliches Hintergrundwissen
Ein weiterer Grund für die Berücksichtigung von Entwickler:innen bei der Formulierung der Spezifikation ist ihr fachlicher Hintergrund. Insbesondere wenn Software für fachlich komplexe Prozesse entwickelt wird, kann eine Spezifikation aus praktischen Gründen nie vollständig sein. Zu gross ist die Menge an impliziten Annahmen und Hintergrundinformationen, die prinzipiell berücksichtigt werden müssen.
Manche Entwickler:innen werden diese spezifischen Informationen bereits kennen, andere nicht. Das ist in diesem Fall weniger eine Frage der Erfahrung als Entwickler:in, sondern vielmehr eine Frage, wie lange die jeweiligen Entwickler:innen in einer bestimmten Branche arbeiten oder welchen fachlichen Hintergrund sie beispielsweise auf Grund anderer Tätigkeiten mitbringen.
Sollen Entwickler:innen Software auf Grundlage einer Spezifikation erstellen, muss diese (zumindest in weiten Teilen) die dafür benötigten Informationen beinhalten. Somit gilt, dass auch die notwendige fachliche Detailtiefe von den jeweiligen Entwickler:innen abhängig sein kann.
In diesem Artikel wurde dafür argumentiert, dass Software-Entwickler:innen nicht nur als Umsetzer von Anforderungen an ein System, sondern auch als Stakeholder verstanden werden sollten. Mit unterschiedlicher Erfahrung, technischem und fachlichem Hintergrund bringen sie ebenso Anforderungen an das System und an den Anforderungsprozess mit. Damit sollten auch sie als Stakeholder berücksichtigt werden.
Sie möchten mehr darüber erfahren, wie unsere in|sure-Software Ihrem Unternehmen dabei hilft, die Herausforderungen der Digitalisierung zu meistern? Dann wenden sie sich gerne an unseren Experten Karsten Schmitt, Head of Business Development
