Requirements-Engineering und -Management in Produktmanagement und Produktlinien-Entwicklung

Die Rolle des Produktmanagements (PM) in der industriellen Software-Entwicklung ist im RequirementsEngineering und -Management (REM) lange Zeit nur wenig beachtet worden. Mit dem Trend zu SoftwareProduktlinien (SPL) anstelle einzeln entwickelter Produkte nimmt die Bedeutung des PM zu. Dieser Artikel umreisst die besonderen Herausforderungen, die PM und SPL an den Umgang mit Requirements stellen. Die Annahmen des Requirements-Engineering und -Management Die Methoden des REM sind weithin durch Annahmen gepragt, die von der Entwicklung von Einzelprodukten ausgehen: Projektumfang und Adressatenkreis („Stakeholder“) stehen weitgehend fest, bevor das RE beginnt. Die Gesamtmenge der relevanten Requirements ist im Wesentlichen klar umgrenzbar; Definition und Umsetzung der Requirements liegen zeitlich (relativ) nah beieinander; Requirements werden nach der Umsetzung kaum mehr benotigt, allenfalls bei spaterer Wartung. —All diese Annahmen treffen bei der industriellen Produktentwicklung und insbesondere bei der Produktlinien-Entwicklung nur selten zu. Es ist also angebracht, die Herausforderungen an das REM in diesem Umfeld naher zu betrachten. REM im Produktmanagement Das Produktmanagement befasst sich mit der Planung und dem Marketing von Produkten uber alle Phasen des Produkt-Lebenszyklus hinweg. Einen guten Uberblick uber die Aufgaben bietet das Pragmatic Marketing Framework [9]. Es definiert die drei Rollen Director Product Strategy, Technical Product Manager und Product Marketing Manager und ihre Aufgaben. Einen engen REM-Bezug weisen nur die beiden ersten Rollen auf. Der Director Product Strategy schafft mit Produktportfolio, Marktanforderungen und ProduktRoadmap vor allem Vorgaben und Rahmenbedingungen fur das REM. Die technischen REM-Aufgaben nimmt der Technical Product Manager wahr. Sie umfassen: Innovation, User Personas, Use Scenarios und Release Milestones. Eine detaillierte Binnensicht auf das Produktmanagement von Software-Produkten bietet das Reference Framework for Product Management von van der Weert, Binkkemper et al. [10]. Es gliedert Produktmanagement in Portfolio Management, Product Roadmapping, Requirements Management und Release Planning. RM ist hier also ein Teilbereich des PM. Es steht in engen Wechselbeziehungen zu Portfoliound Release-Management, die im herkommlichen Verstandnis von REM kaum beachtet werden. Abbildung 1 gibt einen Uberblick uber die Rollen und den Informationsfluss, die dem REM im Produktmanagement zugrunde liegen. Die Produkt-Anforderungen werden von verschiedenen Rollen schrittweise aus den Kundenund Marktanforderungen abgeleitet. Abbildung 1: Beteiligte Rollen und Informationsfluss beim RE im Produktmanagement-Umfeld. In der Praxis fallt auf, dass die Rolle des Requirements Engineers im Umfeld der Produktentwicklung fast nie etabliert ist. Vielmehr teilen Produktmanager und Architekt die REM-Aufgaben unter sich auf. Im Detail geschieht dies auf recht unterschiedliche Weise. Werner beschreibt [11] die schrittweise Transformation von Anforderungen entlang definierter Zustande und Quality Goals, wahrend Fricker [5] die iterative Abstimmung zwischen Requirements-Definition (PM) und Implementation Proposal (Architektur) schildert. Herausforderungen an das REM bei Software-Produktlinien Die Entwicklung von Software-Produktlinien [4][7][8] ist wesentlich komplexer als die Entwicklung von Einzelprodukten. So ist das Requirements-Engineering und -Management fur SPL sehr anspruchsvoll [1][2][3]: Gleichzeitig mussen mehrerer Produktvarianten betrachtet werden, langfristig bindende Architekturalternativen mussen abgewogen werden, Variabilitat muss angemessen beschrieben werden, und Entscheidungen mussen auch fur spatere Zeiten dokumentiert sein. Zugleich aber sind reife REM-Praktiken auch ein wichtiges Erfolgskriterium fur die Entwicklung von Software-Produktlinien. Good Practices fur das REM in der SPL-Entwicklung umfassen unter anderem [1][3]: Klare Kommunikationsund Abstimmungsstrukturen (z.B. Change Control Board, Architecture Review Board), ProgrammManagement-Office als Erganzung des Projektmanagements, explizite und zugleich pragmatische Definition von Variabilitat sowie ein zentrales, werkzeuggestutztes Requirementsund Dokumenten-Management. Die SPL-Prozesse mussen in besonderem Mase auf die Anwendungsdomane und das Umfeld der SoftwareEntwicklung angepasst sein. Zum Beispiel wirkt sich die Anwendungsdomane mit ihrer spezifischen Marktstruktur wesentlich auf die Kommunikationsbeziehungen und die Organisation des REM aus (z.B. Endverbrauchermarkt vs. wenige Einzelkunden). Ahnlich bedeutsam ist die Frage, ob das Produkt ein reines Software-Produkt ist oder ob es sich um ein Hardware/Software-System handelt.