Interdisziplinäres Requirements-Engineering

Transkript

1 Innovation Meets Quality Ausgabe 54 Seite 1 Interdisziplinäres Requirements-Engineering Editorial Kommunikation² Im Requirements-Engineering ist viel Kommunikation erforderlich. Dies gehört zum Basiswissen eines jeden, der schon einmal spezifiziert hat. Die Kommunikation ist in Projekten, die nur eine Disziplin umfassen (wie z.b. ein reines Softwareprojekt) oftmals schon recht schwierig (der Auftraggeber/Produktverantwortliche hat oft zu wenig Zeit, die Requirements werden nur als Texte formuliert und sind oft unklar, etc.). Außerdem gibt es auch in unidisziplinären Projekten meist eine große Zahl von Stakeholdern, die bei der Spezifikation von Requirements mitreden bzw. eingebunden werden sollten. Diese Stakeholder durch eine gute Kommunikation und ein passendes Umfeld zu synchronisieren und auf den gemeinsamen Weg zu bringen gestaltet sich in vielen Fällen als recht schwierig und aufwändig. Im interdisziplinären Umfeld potenzieren sich diese Kommunikationsaufwände. Es gibt vielfach mehr Stakeholder, da ja übergreifend alle Disziplinen berücksichtigt werden müssen. Manch einer verliert in so einem Umfeld den Überblick und die Projekte werden sehr schwer steuerbar. Damit dies nicht passiert, sollte man sich im interdisziplinären Umfeld zeitgerecht vor dem Projektstart überlegen, welche Vorgehen, Methoden und Techniken des Requirements-Engineerings angewendet werden sollen, damit das Projekt ein Erfolg wird. Dieser Knowledge Letter bietet einige Denkanstöße und Hilfestellungen dafür. Viel Spaß beim Lesen und anregende Diskussionen bei der Einführung und Anwendung des interdisziplinären Requirements- Engineerings. Dipl.-Ing. Johannes Bergsmann Berater, Trainer, Ziviltechniker für Informatik Um mit der digitalen Transformation und deren speziellen Ausprägungen wie z.b. Industrie 4.0 oder Internet of Things erfolgreich zu sein, müssen heute Projekte gestartet werden, die im Gegensatz zu früher oft isoliert durchgeführten Systementwicklungen eine übergreifende Sicht auf Business-Prozesse und die betroffenen Fachdomänen berücksichtigen. Der Artikel stellt dar, wie Requirements-Spezifikationen erstellt und gehandhabt werden sollten, wenn in einem interdisziplinären Projekt verschiedene Fachbereiche (z.b. Software, Mechanik, Elektronik, Pneumatik, Produktion, Vertrieb, Marketing, etc.) zusammenarbeiten und doch ein sinnvolles Ganzes als Produkt daraus entstehen soll. Einleitung Gerade in einem interdisziplinären Projekt, in dem verschiedene Fachbereiche zusammenarbeiten, um ein sinnvolles Ganzes als Produkt daraus entstehen zu lassen, ist gutes Requirements-Engineering einer der wichtigsten Erfolgsfaktoren. Es gilt hier, nicht nur innerhalb des Fachbereichs klar zu verstehen, was der Kunde wünscht und wie es umgesetzt werden kann, sondern es müssen auch Sichtweisen aus den anderen Fachbereichen einfließen und berücksichtigt werden. Es sind zusätzliche Abhängigkeiten und Schnittstellen übergreifend zu beachten. Durch effektive Zusammenarbeit zwischen den Fachbereichen lassen sich oft bessere Lösungen kostengünstiger entwickeln. Wichtig dabei ist jedoch, dass die Fachbereiche voneinander wissen, sich entsprechend abstimmen und regemäßig synchronisieren. Nur wenn alle im Gleichklang rudern, geht es zügig voran! Dabei ist vor allem in den hardware-lastigen Fachbereichen ein Umdenken gefragt, da auch hier immer stärker die agilen Methoden zur Anwendung kommen. Wenn man das Thema interdisziplinäres Requirements-Engineering genauer betrachten möchte, sollte man sich unter anderem folgende Fragen stellen: Welche Requirements-Spezifikationstechniken sind im interdisziplinären Umfeld sinnvoll anwendbar? Welche Requirements-Artefakte können/sollen von welchen Fachbereichen erstellt und verwaltet werden und wie können sie in einen sinnvollen Zusammenhang gebracht werden? Wie kann sichergestellt werden, dass der Überblick bei hunderten oder tausenden von Requirements auch fachbereichsübergreifend nicht verloren geht? Wann und mit welchen Techniken kann/soll man die Details in den einzelnen Fachbereichen spezifizieren und inwieweit sollen die Fachbereiche übergreifend die Details kennen? Wer von den zusammenarbeitenden Bereichen kommuniziert wie mit dem Kunden? Wie kann heute auch in hardware-lastigen Fachbereichen agil und synchron zur SW-Entwicklung vorgegangen werden? Nachfolgend werden in diesem Zusammenhang mögliche Wege der Zusammenarbeit aufgezeigt und Techniken im gemeinsamen Umgang mit einzelnen Requirements sowie auch mit der gesamten Spezifikation dargestellt.

2 Innovation Meets Quality Ausgabe 54 Seite 2 Motivation Früher gab es im Engineering sehr oft nur ein einziges System mit klaren Aufgaben und ohne komplexe Schnittstellen. Abb. 1 Systemkomplexität früher In diesen Situationen ist eine isoliert durchgeführte Systementwicklung durchaus möglich und wurde von vielen Engineering Unternehmen auch so umgesetzt. Heute gibt es komplexe und spezielle Ausprägungen und Anforderungen an das Engineering wie z.b. Industrie 4.0 oder Internet of Things. Die Systeme können nicht mehr nur isoliert voneinander betrachtet werden, sondern müssen als Netzwerk von Systemen gesehen werden! Vor allem bezüglich Umsetzungsdauer, Flexibilität, Vorgehensmodell, Qualität, etc. können sich Differenzen ergeben. So kann z.b. das Produktmanagement einen Fokus auf viele Features und schnelle Time-to-Market haben und natürlich beste Qualität wollen. Der Fokus in der SW-Entwicklung ist manchmal vor allem in frühen Requirements-Phasen noch recht unklar. Ganz generell erwartet man sich meist sehr schnelle Zyklen und Reaktionszeiten und die Entwickler wünschen sich eine prototypische und agile Arbeitsweise. Die Hardwareentwicklung dagegen benötigt meist längere Zyklen, hat besondere Restriktionen bezüglich Austauschbarkeit von Komponenten und physikalischen Gegebenheiten und muss ev. von Beginn an klarer definiert sein. Gutes Requirements-Engineering hilft, diese Widersprüche zu reduzieren. Unterschiedliche Vorgehensmodelle Abb. 2 Systemkomplexität heute Konsequenterweise ist daher auch beim Requirements-Engineering eine übergreifende Sicht auf die Business-Prozesse und betroffenen Fachdomänen unbedingt erforderlich! Unterschiedliche Sichten Abb. 4 Interdisziplinäres RE im V-Modell Im V-Modell ist bereits auf der obersten Ebene (Systemebene) ein interdisziplinärer Startpunkt vorgesehen. Die Gefahr lauert dann auf den unteren Ebenen, wenn das Engineering in die einzelnen Disziplinen getrennt wird. Es gibt durch die höhere Systemkomplexität und die unterschiedlichen Fachdomänen natürlich unterschiedliche Sichten und teilweise auch Widersprüche zwischen den Sichten zu berücksichtigen. Abb. 5 Interdisziplinäres RE im agilen Umfeld Abb. 3 unterschiedliche Sichten In der agilen Entwicklung ist die Gefahr einer Trennung weniger gegeben, sofern funktionsübergreifende interdisziplinäre Teams

3 Innovation Meets Quality Ausgabe 54 Seite 3 Abb. 6 RE als Zusammenhalt im interdisziplinären Umfeld gebildet werden. Dies wird in der agilen Vorgehensweise empfohlen. Es ist jedoch darauf zu achten, dass die Cross-Funktionalität sich nicht nur auf Software-Themen und -Funktionen (z.b. GUI, Datenbank, Architektur, Testen, etc.) beschränkt, sondern fachbereichsübergreifende Teams zusammengestellt werden. Die einzelnen Fachthemen laufen grundsätzlich in den meisten Projekten parallel (siehe Abb. 6 RE als Zusammenhalt im interdisziplinären Umfeld ). Requirements sind die Basis für die Zusammenarbeit bzw. den System-Zusammenhalt. Die Requirements sind die Leitschienen für die einzelnen Domänen und verhindern, dass die einzelnen Disziplinen zu weit auseinanderdriften. Wichtig dabei ist, dass die Requirements nicht statisch sind, sondern im Lauf des Projekts angepasst und zwischen den Domänen synchronisiert werden. Abb. 7 Requirements-Break Down vom Groben ins Detail Requirements-Techniken Typischerweise beginnt das Requirements-Engineering auf der obersten Ebene der Ziele und Visionen. Diese müssen dann auf Teilprojekte heruntergebrochen und natürlich untereinander abgestimmt und konsistent gehalten werden (siehe Abb. 7 Requirements-Break Down vom Groben ins Detail ). Hier ist ein wichtiger Ausgangspunkt, an dem Gleichklang hergestellt sein muss. Wenn schon auf der obersten Ebene jeder für sich seine unabhängigen Ziele in den Teilprojekten definiert, wird sich kein Arbeiten im Gleichklang ergeben. Es gilt auch für die anderen Ebenen der Spezifikation, dass diese zwischen allen Disziplinen abgestimmt und konsistent gehalten werden müssen. Auch nach oben zu den Unternehmenszielen sollte immer ein Quercheck erfolgen. Auf den unteren Ebenen ist es dann eventuell nicht mehr möglich, Requirements über alle Disziplinen zu synchronisieren (aufgrund technologischer Unterschiede z.b. zwischen Software und Hardware). Auf jeden Fall soll aber auf die Traceability geachtet und diese konsistent hergestellt werden: z.b. eine Software-Maske mit Eingabeelementen, die einen bestimmten Ausgang der Elektronik auf einen eingestellten Wert setzt bzw. eine Mechanik in eine bestimmte Position bringt. Auch wenn die funktionale Sicht und Spezifikation in den einzelnen Disziplinen in den Detailebenen aufgrund der technologischen Unterschiede nicht mehr direkt synchron gehalten werden können, so kann man mögliche Verbindungen zwischen den funktionalen Einheiten oft über die Prozesse bzw. Use-Cases herstellen und damit eine Verbindung zwischen den Fachdisziplinen herstellen. Abb. 8 Requirements-Engineering Stufen zeigt die typischen Ebenen der Spezifikation. Auf höheren Requirements- Engineering-Ebenen hat man primär eine interdisziplinäre Sicht und diese kann meist auch einfach definiert und aufrechterhalten werden. Je weiter die Spezifikation ins Detail geht, umso mehr wird die Sichtweise unidisziplinär und der Abgleich der Sichten muss durch verbindende Techniken wie z.b. übergreifende Prozessabläufe zusammengehalten werden.

4 Innovation Meets Quality Ausgabe 54 Seite 4 Grafiken oder Screen-Mockups Abb. 8 Requirements-Engineering Stufen Zum gemeinsamen Verständnis ist es sinnvoll, wenn sich interdisziplinäre Teams über die Disziplinen hinweg entlang des Benutzungs-/Bearbeitungsprozesses mit dem Zielsystem auseinander setzen (z.b. Start mit einer Eingabe in einer SW-Maske, Setzen eines Wertes auf einem Steuerungsausgang, Drehen eines Motors, Bewegen eines HW-Teils, Rückmeldung der HW- Stellung durch einen Sensor an die Steuerung, Auswertung der Position durch die SW). Text sollte wenn möglich nur auf der obersten Ebene (z.b. für Ziele und High-Level Anforderungen) sowie auf der untersten Spezifikationsebene (wenn es stark domänenspezifisch wird) als dominierende Spezifikationstechnik verwendet werden. In den anderen Spezifikationsebenen, vor allem wenn interdisziplinär spezifiziert wird, soll Text nur als ergänzendes Element zum Einsatz kommen (z.b. als ergänzende Erklärung zu Diagrammen, Modellen, Grafiken oder Screen-Mockups). Interdisziplinäre Teams & Kommunikation Abb. 9 Interdisziplinärer spezifizierter Anwendungsprozess Welche Technik ist interdisziplinär geeignet? Es gibt verschiedene Techniken, wie die Spezifikation durchgeführt werden kann, wie z.b. textbasiert, modellbasiert, mittels Prototyping oder mit agilen Spezifikationstechniken. In vielen Projekten zeigt sich, dass visuelle Techniken am besten für interdisziplinäres Arbeiten geeignet sind. Nachfolgend sind einige Bespiele angeführt: Ablauf- und Strukturdiagramme Es müssen Vertreter der unterschiedlichen Fachdomänen in die Teams eingebunden werden. Dies muss nicht dauerhaft erfolgen. Jedoch sollen regelmäßige Abstimmungen stattfinden (z.b. Teilnahme des Elektronik-Product-Owners/ Managers in den Planning-Meetings des SW-Teams). Generell ist hier systemisches Denken und ein mechatronischer Ansatz bei allen Beteiligten gefordert. Eine initiale gemeinsame Sicht und gemeinsames Verständnis ist essentiell. Es ist wichtig, die Sprache und das Thema der anderen Disziplinen zu verstehen! Abb. 10 Interdisziplinäres Team

5 Innovation Meets Quality Ausgabe 54 Seite 5 Dafür ist eine regelmäßige Kommunikation unerlässlich. Agile Prinzipien und Techniken können hier helfen, das Wissen über die Fachdomänen zu verteilen. Weitere unterstützende Maßnahmen sind: Eine fachübergreifende Kommunikationsdrehscheibe etablieren und eine gemeinsame Sicht schaffen Unklarheiten zwischen den Fachdomänen übersetzen die Domänen hinweg durchzuführen und damit z.b. das interdisziplinäre Änderungsmanagement zu unterstützen. Änderungen von Requirements sind prinzipiell nichts Negatives. Sie weisen drauf hin, dass sich die Stakeholder mit dem System auseinandersetzen. Viele Änderungen erfordern jedoch einerseits einen hohen Kommunikations-/Abstimmungsbedarf und andererseits auch ein nachvollziehbares Management dieser Änderungen. Klarheit über die Zusammenhänge der Requirements schaffen, z.b. welche Requirements sind betroffen, wenn an irgendeiner Stelle/Ebene etwas geändert wird? Information und Diskussion über ALLE Änderungen. Es sollte immer bewusst nachgedacht werden was passiert, wenn in einer Disziplin etwas geändert wird und die anderen nichts davon wissen. Funktionale und nicht-funktionale Sicht Auf die nicht-funktionalen Requirements muss im interdisziplinären Umfeld besonders geachtet werden. Für die funktionalen Requirements ist meist der jeweilige Fachbereich zuständig wie z.b. für SW-Funktionen, HW-Funktionen, Elektronikfunktionen, Mechanikfunktionen, etc. Die nicht-funktionalen Requirements sind jedoch oft Querschnittsthemen! Daher ist hier die Koordination der Disziplinen unbedingt notwendig. Viele nicht-funktionale Themen wie Security, Usability, Safety, etc. sind z.b. in der ISO angeführt und erfordern jeweils auch Spezialisten aus den verschiedenen Fachdomänen. Viele funktionale Requirements (egal ob aus SW, HW, Elektronik, etc.) müssen gegen die relevanten nicht-funktionalen Anforderungen geprüft werden. Es ist daher gerade bei den nicht-funktionalen Anforderungen ein interdisziplinärer Austausch erforderlich und wichtig. Abb. 11 Anforderungskonfigurationen und -baselines Anforderungskonfigurationen und -baselines (gekennzeichnete Konfigurationen, die bestimmte Versionen der Anforderungen umfassen) müssen über alle Disziplinen hinweg konsistent definiert und geführt werden! Durch die passende Auswahl kann eine interdisziplinäre Toolbasis geschaffen werden, die neben der inhaltlichen Verwaltung von Requirements z.b. auch Wissensmanagement, Change-Management, Task-Management und Workflow-Komponenten beinhaltet (und somit nicht nur rein inhaltsbasierte, sondern auch aktive Komponenten umfasst). Management von Requirements im interdisziplinären Umfeld Wichtig für das Management der Requirements ist eine gemeinsame, solide Tool-Basis. Unterschiedliche Tools, die nicht gut integriert sind, blockieren die Kommunikation. Ungünstig ist z.b. wenn das HW-Team Catia als CAD-Programm, die Elektronikgruppe das Tool Polarion, das SW-Team Jira und Confluence und das Management Word und Excel zur Verwaltung der Requirements verwenden. Soweit als möglich soll ein gemeinsames RE-Tool über die Disziplinen hinweg verwendet werden. Dies ist erfahrungsgemäß aus verschiedenen Gründen nicht immer möglich. Auf jeden Fall sollten jedoch alle in den einzelnen Disziplinen verwendeten RE-Tools datenbankbasiert sein, Versions- & Konfigurationsmanagement unterstützen sowie offene Schnittstellen haben, damit zumindest eine einfache Integration der Tools möglich ist, auch wenn nicht übergreifend überall dasselbe Tool eingesetzt wird. Dies hilft auch, die Traceability-Verlinkung über Abb. 12 Interdisziplinäre Toolbasis

6 Innovation Meets Quality Ausgabe 54 Seite 6 Resümee Requirements-Engineering Techniken und Methoden sind für alle Fachbereiche und Disziplinen anwendbar. Die Bereiche und die darin angewendeten ev. auch unterschiedlichen Prozessmodelle müssen aufeinander abgestimmt sein. Requirements-Engineering ist die Basis für den Zusammenhalt zwischen den Disziplinen! Es ist wichtig, interdisziplinäre Teams und Sichten zu schaffen. Die Teams müssen intensiv kommunizieren und Wissen über die Bereiche verteilen. Dies ist nicht nur initial wichtig, sondern auch bei allen Änderungen von Requirements im Laufe des Projekts. Traceability, Konfigurationen und Baselines helfen dabei, domänenübergreifend den Überblick zu bewahren. Es müssen auch Kommunikationsstrukturen geschaffen und einheitliche/ passende Tools verwendet bzw. passend integriert werden. Interdisziplinäres Requirements-Engineering ist aufwändiger als unidisziplinäres RE, hat aber viele Vorteile und rechnet sich langfristig. Schlüsselfaktoren für den Erfolg sind Klare, übergreifende Ziele & Anforderungen Gemeinsames Verständnis zwischen den Disziplinen Klare Synchronisationspunkte Möglichst ähnliche Methodiken/Vorgehensweisen/Tools im Requirements-Engineering anwenden Regelmäßige Kommunikation, interdisziplinäre Teams Offenheit: Ideen aus anderen Bereichen zulassen! Literatur & Links Bergsmann, Unterauer, Requirements Engineering für die agile Softwareentwicklung, dpunkt Verlag, 2014 IEEE , Recommended Practice for Software Requirements Specifications, Autor Zitate One person's "paranoia" is another person's "engineering redundancy." Marcus J. Ranum The product will reflect the organizational structure that produced it. Leistungen von Software Quality Lab Conway s Law Im Thema Requirements-Engineering unterstützen die Experten von Software Quality Lab durch folgende Leistungen: Aufbau und Einführen eines interdisziplinären Requirements- Engineering Vorgehens Coaching und Beratung bei der Ausarbeitung und Anwendung von Methoden und Techniken im interdisziplinären Requirements-Engineering Unterstützung bei Basisthemen wie Changemanagement, Konfigurationsmanagement, Priorisierung, Aufwandsschätzung, Traceability, etc. Durchführen von Workshops mit interdisziplinären Teams Einführung und Anwendung von Requirements Methoden sowohl agil als auch nicht-agil Erstellen und Review von Artefakten im Requirements-Engineering Schulungen in allen Themen des Systems- und Software-Lebenszyklus wie Requirements-Engineering, User-Experience, Architektur und Modellierung, agile Vorgehensweisen, Projekt- und Produktmanagement, Kommunikation und Führen von Teams, Tool-Schulungen, etc. Methodische Hilfe bei allen Qualitäts- und Test-Themen in der System- und Software-Entwicklung Analyse und Optimierung der gesamten Entwicklungsprozesse vom Requirements-Engineering, Projekt- und Produktmanagement, über Architektur, Coding, bis zum Testen, der Auslieferung und dem Betrieb und Wartung. Tool Evaluation Center zur Auswahl von passenden Tools sowie Unterstützung bei der Tool-Anpassung, Integration, Schulung und Einführung Impressum Dipl.-Ing. Johannes Bergsmann Geschäftsführender Gesellschafter Berater & Trainer bei Software Quality Lab Der Quality Knowledge Letter ist ein periodisches Informationsmedium von Software Quality Lab und dessen Partnern mit dem Schwerpunkt SW-Qualität. Weitere Infos zu diesem und anderen Themen finden Sie auf