Anforderungsmanagement: Der Kernprozess einer Mechatronikentwicklung

Transkript

1 Anforderungsmanagement: Der Kernprozess einer Mechatronikentwicklung Thomas Reiß Technische Universität München Institut für Informatik Boltzmannstr. 3, Garching Jürgen Schuller Audi AG Entwicklung Fahrwerkregelsysteme Ingolstadt , Zusammenfassung Die Anzahl und Komplexität mechatronischer Systeme in Fahrzeugen wächst stetig an. Dadurch wird es schwieriger, hohe Qualitätsstandards zu gewährleisten und systematische Fehler zu vermeiden. Mit einem strukturierten Vorgehen in der Entwicklung kann dieser Tatsache entgegengewirkt werden. In diesem Beitrag wird ein workflowbasierter Ansatz für das Requirements Engineering vorgestellt. Weiter wird die Einbindung des Qualitäts- und Änderungsmanagements in das Konzept diskutiert. Damit wird eine prozessorientierte Entwicklung ausgehend vom Requirements Engineering vorgestellt, die eine effiziente werkzeuggestützte Prozessumgebung ermöglicht. Die Umsetzung des Ansatzes wird an Hand einer prototypischen Implementierung veranschaulicht. Schlüsselwörter Automotive Systems Engineering, Requirements Management, Traceability, Business Process Modelling, Change Management

2 Seite 204 Reiß, Schuller 1 Motivation Mechatronische Systeme wie elektronische Lenkungssysteme, aktive Allradsysteme etc. beeinflussen wesentlich die Entwicklung im Automobilsektor. Ein steigender Funktionsumfang der einzelnen Systeme ebenso wie die Zunahme an interagierenden mechatronischen Systemen erschwert die Erfüllung gleich bleibend hoher Qualitätsstandards ebenso wie die Vermeidung systematischer Fehler. Ein strukturiertes Vorgehen in der Entwicklung kann zur Erreichung hoher Qualitätsund Sicherheitsstandards beitragen. Zentrale Teilprozesse sind das Requirements Engineering (RE), das Änderungsmanagement (AEM) sowie das Qualitätsmanagement (QM). Da Anforderungen die Grundlage für die Entwicklung darstellen, wird die Qualität des Produktes über die Qualität der Anforderungen beeinflusst. Dennoch werden RE, AEM und QM zumeist als separate Teilprozesse behandelt. In diesem Beitrag wird für die Serienentwicklung eines mechatronischen Systems im Automobilsektor ein Konzept vorgestellt, welches das Zusammenspiel von RE, AEM und QM unterstützt. Ausgehend von einem workflowbasierten RE erfolgt die Einbindung des Änderungsmanagements in das RE. Durch die Zuordnung von Qualitätsattributen [IEEE98], [RS07] zu den Lebenszyklen von Anforderungen und Anforderungsspezifikationen wird die Einbindung des QM in das RE abgebildet. Weitere Unterstützung des QM s durch das RE wird durch Metriken gegeben, welche auf dem workflowbasierten RE basieren. In Kapitel 2 wird eine kurze Einführung in die Serienentwicklung im Automobilsektor gegeben. In diesem Kontext erfolgt eine kurze Einführung in das RE, das AEM und das QM. Dabei wird auf bestehende Ansätze eingegangen. In Kapitel 3 wird das workflowbasierte RE-Konzept hergeleitet, welches im vierten Kapitel um Aspekte des AEM s und QM s ergänzt wird. Kapitel 5 gibt einen Einblick in die werkzeuggestützte Anwendung des Ansatzes. In Kapitel 6 erfolgen eine Zusammenfassung der Arbeit und ein Ausblick auf weiterführende Betrachtungen. 2 Grundlagen Die Entwicklung im Automobilsektor kann auf unterschiedlichen Ebenen betrachtet werden. Auf Fahrzeugebene werden Kundenfunktionen erhoben und die Umsetzung der Anforderungen verschiedenen Systemen zugewiesen. Die Entwicklung einzelner Systeme wird in dieser Arbeit betrachtet.

3 Anforderungsmanagement: Der Kernprozess einer Mechatronikentwicklung Seite Systementwicklung im Automobilsektor Die Systementwicklung im Automobilsektor unterteilt sich in Vor- und Serienentwicklung [Rei08]. In der Vorentwicklung wird der Kern der funktionalen Systemanforderungen erhoben und die technische Realisierbarkeit hinsichtlich der Serientauglichkeit bewertet. In der Serienentwicklung wird das System basierend auf der durch den Prototyp gegebenen Systemarchitektur und der implizit gegebenen Aufteilung der Anforderungen zur Serienreife weiterentwickelt. Kern der RE-Aktivitäten in dieser Phase ist das Requirements Management, welches die Erfassung, Verwaltung und Bereitstellung von Informationen zu Anforderungen umfasst. Da Anforderungen die Grundlage für die Entwicklung darstellen, nimmt das Requirements Management eine zentrale Rolle in der Entwicklung ein. Die Erfassung von Anforderungen und (Traceability-)Informationen zu diesen muss daher unterstützt durch ein geeignetes Konzept erfolgen. Dabei kann über die Erfassung und Bereitstellung von Informationen zum Anforderungslebenszyklus eine Interaktion mit weiteren Prozessaktivitäten erzielt werden. 2.2 Requirements Engineering Stand der Technik In der Literatur existieren zahlreiche Überlegungen zum Requirements Engineering. Diese Ansätze befassen sich unter anderem mit Methoden zur Anforderungsfestlegung (z.b. [Lam04]) sowie Beschreibungsformen für Anforderungen (z.b. [BS01]). Methodische Unterstützung für das Requirements Management wird durch Referenzmodelle gegeben (z.b. [BGK+07], [RJ01]). Diese Modelle beschreiben generisch, welche Informationen zu Anforderungen entstehen und in welchem Bezug sie zu den Anforderungen stehen. Da die Anwendung dieser abstrakten Modelle einen hohen Anpassungsaufwand erfordert, wird in [MPR07] ein detailliertes Artefaktemodell für eine Entwicklung nach dem Unified Process vorgestellt. Für eine Entwicklung im Automobilsektor ist soweit den Autoren bekannt eine solche Betrachtung bisher nicht durchgeführt worden. Betrachtet man das Requirements Management in der Anwendung, so wird ersichtlich, dass eine detaillierte Beschreibung des Entwicklungsablaufs aus Sicht des Requirements Engineering auch für die Praxisanwendung erforderlich ist. Die Umsetzungen in der industriellen Anwendung sind werkzeuggetrieben und lassen rein dokumentenbasierte oder anforderungsbasierte Arbeitsweisen zu. Das Zusammenspiel mit weiteren Prozessaktivitäten wie dem AEM oder dem QM findet dabei kaum Beachtung [Rei08].

4 Seite 206 Reiß, Schuller 2.3 Änderungsmanagement Im Zuge einer Entwicklung kommt es z.b. auf Grund negativer Testergebnisse zu Änderungen. Werden diese nicht strukturiert in die Entwicklung eingebracht, so kann sich dies auf die Qualität des Produktes negativ auswirken. Das AEM trägt dazu bei, dass Auswirkungen von Änderungen ermittelt werden und erforderliche Entwicklungsaktivitäten vollständig umgesetzt werden. Dadurch wird das Auftreten von unerwünschten Nebeneffekten auf Grund von Änderungen verringert und die Qualität des Systems positiv beeinflusst. Vorgehen zu Änderungsmanagement werden z.b. in [RBH+08] beschrieben. Allerdings erfolgt die Betrachtung des Änderungsmanagements losgelöst von einem Requirements Management Ansatz. 2.4 Qualitätsmanagement im Requirements Engineering Aufgabe des Qualitätsmanagements ist die Gewährleistung eines hohen Qualitätsstandards des Produktes. Hierzu zählen sowohl produktbezogene als auch prozessbezogene Aktivitäten [ISO9000]. Dies umfasst auch die Sicherstellung qualitativ hochwertiger Anforderungen und Anforderungsspezifikationen. Um die Qualität einer Anforderungsspezifikation zu gewährleisten, werden in der Literatur Spezifikationsvorlagen bereitgestellt [RR07], [IEEE98]. Des Weiteren werden in [IEEE98] Kriterien für eine qualitativ hochwertige Spezifikation gegeben. Eine Übertragung auf einzelne Anforderungen erfolgt in [RS07]. Möglichkeiten der Kontrolle der Qualitätsattribute stellen neben der inhaltlichen Überprüfung zu quality gates [RR99] Metriken dar. Für die oben erwähnten Qualitätsattribute werden in [RR06], [RS07] Maßzahlen definiert, welche jedoch Interpretationsspielraum lassen und manuell ausgewertet werden müssen. In [WRH99-ol] werden für natürlichsprachlich formulierte Dokumente häufig verwendete Wörter, Phrasen und Strukturen mit Hilfe empirischer Studien Qualitätsattributen zugewiesen. Unter Verwendung des Automated Requirements Measurement Tool können diese semantischen und syntaktischen Regeln für natürlichsprachlich formulierte Dokumente angewandt und ausgewertet werden. Soweit den Autoren bekannt, wurden bisher keine Betrachtungen durchgeführt, wann Qualitätsgrößen im Anforderungslebenszyklus überprüft und wie erfasste Größen zur Auswertung in Metriken herangezogen werden können. 3 Workflowbasiertes Requirements Engineering Die Betrachtungen des Requirements Engineering haben gezeigt, dass für die Serienentwicklung im Automobilsektor eine Detailbetrachtung erforderlich ist. Am Beispiel des AEM s und des QM s wurde weiter aufgezeigt, dass das Zusammenspiel des RE mit weiteren Prozessaktivitäten optimiert werden kann. Diesen bei-

5 Anforderungsmanagement: Der Kernprozess einer Mechatronikentwicklung Seite 207 den Herausforderungen wird durch einen ganzheitlichen workflowbasierten RE- Ansatz begegnet. Hierzu wird der Geschäftsprozess der Entwicklung abgebildet. Aus diesem wird ersichtlich, welche Artefakte wann in einer Entwicklung entstehen und welche Abhängigkeiten zwischen den Artefakten bestehen. Diese Informationen werden in einem Abhängigkeitsmodell erfasst. Anschließend werden Workflows zu den Artefakten definiert und die Abhängigkeiten über die Interaktion der Workflows abgebildet. 3.1 Geschäftsprozessmodellierung In dieser Arbeit dient die Geschäftsprozessmodellierung der Herausarbeitung der Artefakte, die im Rahmen einer Systementwicklung entstehen. Hierzu erfolgte eine detaillierte Modellierung des Entwicklungsprozesses, welcher sich in der Automobilbranche am V-Modell orientiert [Rei08]. Dabei ist zu beachten, dass teilweise Aktivitäten implizit in der Vorentwicklung durchgeführt und erst in der Serienentwicklung dokumentiert werden. Als Ausgangspunkt für weitere Betrachtungen dient der in Bild 1 dargestellte abstrakte Geschäftsprozess auf Ebene der Systementwicklung. Bild 1: Geschäftsprozess: impliziter Ablauf der Systementwicklung Ausgehend von dieser abstrakten Geschäftsprozess lässt sich durch eine detaillierte Modellierung des Architekturschrittes 1. der Schritt der Anforderungsverfeinerung beschreiben (Bild 2 gestricheltes Rechteck). Legt man eine Klassifizierung in funktionale und nicht-funktionale Anforderungen zu Grunde 2, ergeben sich folgende Aussagen: Funktionale Anforderungen werden über die Hierarchieebenen des Systems bis zur Modulebene verfeinert. 1 In dieser Arbeit werden Aktivitäten im Zuge des Systemdesigns unter dem Begriff Architekturschritt zusammengefasst. 2 Eine weitere Unterteilung der nicht-funktionalen Anforderungen erfolgt nicht, um die Anwendung des Ansatzes möglichst flexibel zu gestalten.

6 Seite 208 Reiß, Schuller Nicht-funktionale Anforderungen resultieren aus Normen/Richtlinien und Standardanforderungen. Eine Zuordnung von Maßnahmen zu den aus Normen/Richtlinien und Standardanforderungen erfolgt auf Teilsystemebene. Unterschiedliche Formen von Maßnahmen stellen Prozessanforderungen, Architekturanforderungen und funktionale Anforderungen dar. Eine weitere Detailbetrachtung des Geschäftsprozesses stellt die Modellierung des Geschäftsprozesses eines (Teil-) Systems dar (Bild 2 horizontales Rechteck). Aus dieser Betrachtung erhält man Artefakte die im Lebenszyklus einer Anforderung entstehen, wie z.b. Testfälle. 3.2 Abhängigkeitsmodell Aus der Modellierung des Geschäftsprozesses resultieren Artefakte die in Abhängigkeit gesetzt werden (Bild 2). Bild 2: Abhängigkeitsmodell

7 Anforderungsmanagement: Der Kernprozess einer Mechatronikentwicklung Seite 209 Einem Teilsystem werden eine Anforderungs- und mindestens eine Testspezifikation zugeordnet. Die Anforderungsspezifikation setzt sich wiederum aus verschiedenen Artefakten zusammen, zu denen funktionale und nicht-funktionale Anforderungen zählen. Während funktionale Anforderungen aus funktionalen Anforderungen anderer Teilsysteme oder aus Normen und Richtlinien resultieren, werden nicht-funktionale Anforderungen ausschließlich aus Normen und Richtlinien abgeleitet. Inhalt der Testspezifikation stellen Testfälle unterschiedlicher Art (Testumgebung, Testspezifikationstechnik, ) dar, die sich auf Anforderungen beziehen. 3.3 Workflows Aus den Geschäftsprozessen ergeben sich Abläufe, die als Workflows 3 von Artefakten des Abhängigkeitsmodells modelliert werden können. Auf Grund der Abhängigkeiten zwischen den Artefakten ist die Definition des Workflows eines Artefaktes nur im Kontext möglich. Ein Beispiel für die Workflowmodellierung ist in Abbildung 3 dargestellt. Dabei interagieren die Workflows der Anforderung und der Anforderungsspezifikation im Status Review Anforderung. Soll ein Review aller Anforderungen einer Spezifikation erfolgen, so werden über einen Trigger alle Anforderungen, die den Status Review Anforderung noch nicht erfolgreich durchlaufen haben in diesen Status gesetzt. Dadurch wird dem Entwickler die Möglichkeit gegeben das Review für einzelne Anforderungen oder für alle Anforderungen einer Spezifikation durchzuführen. 4 QM im workflowbasierten RE 4.1 Zuordnung von Qualitätsattributen Im Workflow der Spezifikation erfolgt eine Unterscheidung zwischen Review Anforderung und Review Spezifikation. Neben der Möglichkeit einer dokumenten- und anforderungsbasierten Arbeitsweise, kann eine Fokussierung der zu prüfenden Qualitätsattribute erfolgen. Hierzu wird die folgende Zuordnung von Qualitätsattributen 4 [IEEE98], [RS07] vorgeschlagen: 3 Im Gegensatz zur Geschäftsprozessmodellierung, in der Aktivitäten dargestellt werden, werden in den Workflows die Zustände der Artefakte modelliert. 4 Die Definition der Qualitätsattribute wurde im Zuge der Zuordnung nach dem Verständnis der Autoren angepasst. Insbesondere wurde das Attribut realisierbar nicht zugewiesen, da dies in der Serienentwicklung durch die Vorentwicklung bereits nachgewiesen ist. Weiter wurde Bewertet und Klassifizierbar in 'attributiert' zusammengefasst

8 Seite 210 Reiß, Schuller Bild 3: Beispiel der Interaktion von Workflows durch Trigger Review Spezifikation: o Vollständigkeit: alle Normen/Richtlinien, die für den Teilsystemtyp relevant sind, sind aufgeführt; Alle ergänzenden Artefakte (Systembeschreibung, etc. liegen vor); Das Verhalten wird vollständig beschrieben. o Konsistent: Die Anforderungen der Spezifikation widersprechen sich nicht, das Verhalten des Teilsystems beschreibt oder detailliert das Verhalten des übergeordneten Teilsystems. Review funktionale Anforderung: o Korrekt: Der Definitionsbereich ist Teilmenge des Definitionsbereichs der übergeordneten Anforderung o Prüfbar: Eine maximal zulässige Abweichung für die Anforderung ist definiert

9 Anforderungsmanagement: Der Kernprozess einer Mechatronikentwicklung Seite 211 o Eindeutig 5 : Für jede Eingangskombination, die durch die Anforderung beschrieben wird gibt es einen eindeutigen Ausgabewertebereich. o Notwendig: Die Anforderung hat mindestens einen Vorgänger. o Verfolgbar: Der Vorgänger der Anforderung ist in der Anforderung ersichtlich (textuell aufgeführt oder verlinkt). Review nicht-funktionale Anforderung: o Prüfbar: Es ist mindestens ein Abnahmekriterium definiert (Review, Stichprobe, etc.) o Eindeutig: Die Maßnahme ist eindeutig beschrieben (Prozessbeschreibung liegt vor, Architekturvorgabe ist beschrieben) o Verfolgbar: Der Vorgänger der Anforderung ist in der Anforderung ersichtlich (textuell aufgeführt oder verlinkt) Das Attribut Verstehbar ist in allen Reviews zu berücksichtigen. Des Weiteren wird das Attribut Vollständigkeit zwischen den Anforderungen und deren Nachfolgern im Hinblick auf die vollständige Ableitung betrachtet. Dies kann jedoch erst erfolgen, wenn die Spezifikation eines Teilsystems sowie der Teilsysteme in die es zerlegt wird vorliegen. 4.2 Definition von Qualitätsmetriken In der Anwendung ist es zumeist auf Grund zeitlicher Restriktionen nicht möglich, alle Qualitätsattribute zu Beginn einer Entwicklung zu erfüllen. Dies betrifft z.b. das Attribut Verfolgbar. Da in frühen Entwicklungsphasen die zugehörige Anforderung noch nicht dokumentiert vorliegt oder der Fokus zuerst darauf ausgerichtet wird ein Teilsystem möglichst umfangreich mit prüfbaren Anforderungen zu beschreiben, wird in diesen Phasen das Review einer Anforderung trotz dieser Defizite als in Ordnung (zu diesem Entwicklungsstand) eingestuft. In solchen Fällen ist es hilfreich, über Metriken Aussagen zum Entwicklungsstand treffen zu können. Dabei ist zu beachten, dass die Auswertung der Maßgrößen automatisiert erfolgen kann und die Vergleichbarkeit gewährleistet ist. Im Folgenden werden einige Metriken, die diese Rahmenbedingungen erfüllen, definiert. Hierzu sei: (r): {Vorgänger der Anforderung r} 5 Die eindeutige Identifizierbarkeit der Artefakte durch das Datenmanagementwerkzeug wird vorausgesetzt.

10 Seite 212 Reiß, Schuller (r): {Nachfolger der Anforderung r} R = Kardinalität der Menge an funktionalen Anforderungen R Weiter wird mit einem hochgestellten a die absolute Metrik, mit einem hochgestellten rel die relative Metrik bezeichnet. Dann definieren wir die folgenden Größen: Rückwärtsverfolgbarkeit: a (R) : r R : (r) 0, b rel b (R) : a b (R) R Diese Größe beschreibt für eine definierte Menge an Anforderungen (z.b. die Anforderungen eines einzelnen oder mehrerer Teilsysteme, ausgenommen Systemanforderungen 6 ) den Anteil der Anforderungen, die zu einem Vorgänger verlinkt sind. Am Ende der Entwicklung muss die Größe rel b a b der Anzahl der Anforderungen entsprechen, für muss sich der Wert eins ergeben. Andernfalls wären nicht erforderliche Anforderungen spezifiziert. Vorwärtsverfolgbarkeit: a (R) : r R : (r) 0, f rel f (R) : a f (R) R Diese Größe beschreibt für eine definierte Menge an Anforderungen (ausgenommen von Modulanforderungen 7 ) den Anteil der Anforderungen, die zu einem Nachfolger verlinkt sind. Am Ende der Entwicklung muss die Größe a f der Anzahl der Anforderungen entsprechen, für muss sich der Wert eins ergeben. Andernfalls würden Anforderungen existieren, die nicht umgesetzt sind. rel f Verfolgbarkeit: a (R) : r R : (r) 0 (r) 0, rel (R) : a (R) R Diese Größe beschreibt für eine definierte Menge an Anforderungen den Anteil der Anforderungen der sowohl vorwärts als auch rückwärtsverfolgbar ist. Neben diesen Metriken, die auf der Verlinkung der Anforderungen basieren, ermöglicht das workflowbasierte RE die Auswertung von Informationen aus den Lebenszyklen der Anforderungen. Aussagen über Status der Anforderungen, Anzahl der Änderungen und Anzahl Reviewdurchläufe für eine Menge an Anforderungen sind einige Beispiele solcher Auswertungen. 6 Systemanforderungen sind zu Szenarien aus der Vorentwicklung verlinkt 7 Diese Anforderungen haben als nachfolgendes Artefakt eine Implementierung

11 Anforderungsmanagement: Der Kernprozess einer Mechatronikentwicklung Seite Einbindung des Änderungsmanagements In den workflowbasierten AM-Ansatz, welcher die Verfolgbarkeit über Lebenszyklus gewährleistet, wurde der Ablauf des Änderungsverfahrens nach [RBH+08] integriert. Die Umsetzung dieses Ablaufs ist in Bild 4 dargestellt. 5 Werkzeugunterstützung Basierend auf MKS Integrity wurde das vorgestellte Konzept umgesetzt. Dabei wurden die Artefakte des Abhängigkeitsmodells mit ihren Workflows implementiert. Die entsprechend dem Abhängigkeitsmodell erforderlichen Artefakte zu einem Teilsystem werden als Vorlagen automatisch generiert. Das Zusammenspiel der Workflows wird über Trigger realisiert. Die Zuordnung der Qualitätsattribute erfolgt durch die Bereitstellung von Checklisten in der Aktivität der Reviewdurchführung, während Qualitätsmetriken durch Auswertungen der Informationen automatisiert generiert werden können. Die Umsetzung der Einbindung des Änderungsmanagements in das workflowbasierte RE ist in Bild 4 dargestellt. 6 Zusammenfassung und Ausblick In dieser Arbeit wurde ein workflowbasiertes Requirements Engineering eingeführt. Über das RE hinaus wurde die Einbindung des QM s und des AEM s betrachtet. Damit wurden die bestehenden RE-Ansätze um eine implementierungsnahe detaillierte Beschreibung ergänzt, die zudem die Einbindung weiterer Prozessaktivitäten explizit mitberücksichtigt. Ziel weiterer Betrachtungen wird es zum einen sein, die Geschäftsprozesse zu beschreiben und den workflowbasierten Ansatz weiterzuverfolgen. Zum anderen soll die Einbindung weiterer Prozessaktivitäten wie z.b. dem Testmanagement betrachtet werden. Hinsichtlich der Umsetzung ist die Erweiterung der prototypischen Umsetzung geplant. Durch die Anwendung des Ansatzes in der Praxis sollen mittelfristig Prozessoptimierungen ebenso wie Aussagen hinsichtlich der Eignung von Werkzeugen unter realen Bedingungen abgeleitet werden. 8 MKS Integrity 2007 ist ein Werkzeug der Firma MKS Inc. zur Unterstützung der Entwicklung u.a. in den Bereichen Requirements Management, Configuration Management und Test Management. (Siehe auch

12 Seite 214 Reiß, Schuller CCB Bild 4: Werkzeugumsetzung am Beispiel des Änderungsmanagements: Erstellung & Befüllung eines Änderungsantrages (oben), Generierung von Tasks für Entwicklung und Verifikation nach Genehmigung der Änderung (mitten), Abschluss der Änderung im CCB (unten).

13 Anforderungsmanagement: Der Kernprozess einer Mechatronikentwicklung Seite 215 Literatur [BGK+07] [BS01] [IEEE98] BROY, M.; GEISBERGER, E.; KAZMEIER, J; RUDORFER, A.; BEETZ, K.: Requirements Engineering Reference Model. GI Informatik Spektrum 3, S , 2007 BROY, M.; STOLEN, K.: Spezification and Development of interactive systems. Springer, New York, Berlin, Heidelberg, 2001 INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERIS: IEEE Recommended Practice for Software Requirements Specifications (IEEE Std ), 1998 [ISO9000] INTERNATIONAL STANDARDIZATION ORGANISATION: ISO 9000: Quality management systems Fundamentals and vocabulary, 2006 [Lam04] [MPR07] [RBH+08] [Rei08] [RJ01] [RR99] [RR06] [RR07] [RS07] [WRH99-ol] VAN LAMSWEERDE, A.: Goal-Oriented Requirements Engineering: A Roundtrip from Research to Practice. Proceedings of 12th IEEE Joint International Requirements Engineering Conference, S. 4-8, 2004 MÄDER, P.; PHILIPPOW, I.; RIEBISCH, M.: A Traceability Link Model for the Unified Process. Proceedings 8th Intl. Conf. on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, S , 2007 RAUSCH, A.; BERGNER, K.; HÖHN, R. UND HÖPPNER, S.: Das V-Modell XT: Grundlagen, Methodik und Anwendungen, Springer, Berlin Heidelberg, 2008 REISS, T: Traceability - Aktuelle Herausforderungen in der Systementwicklung im Automobilsektor. Technische Universität München, Institut für Informatik, TUM-I0810, 2008 RAMESH, B.; JARKE, M.: Toward Reference Models of Requirements Traceability. IEEE Transactions on Software Engineering 27, S.58-93, 2001 ROBERTSON, J.; ROBERTSON, S.: Mastering the Requirements Process. ACM Press, 1999 RECKNAGEL, M.; RUPP, C.: Messbare Qualität in Anforderungsdokumenten, Vertikal (2), pp12-17, 2006 ROBERTSON, J.; ROBERTSON, S.: Volere: Requirements Specification Template, RUPP, C UND DIE SOPHISTEN: Requirements Engineering und -Management - Professionelle, iterative Anforderungsanalyse für die Praxis, Hanser, München, Wien, 2007 WILSON, W.M., ROSENBERG, L.H.; HYATT, L.E.: Automated Quality of Natural Language,

14 Seite 216 Reiß, Schuller Autoren Thomas Reiß ist seit 2005 bei der AUDI AG im Bereich Entwicklung Fahrwerkregelsysteme tätig. In der Entwicklung eines mechatronischen Systems trägt er die Verantwortung für die Prozesseinhaltung und Optimierung der Entwicklungsaktivitäten. In Kooperation mit der TU München, Lehrstuhl für Software & Systems Engineering, erarbeitet er im Rahmen seiner Doktorarbeit ein Konzept zur Optimierung von Entwicklungsabläufen basierend auf einem workflowgesteuerten Requirements Engineering. Dr. Jürgen Schuller ist seit 2003 bei der AUDI AG verantwortlich für funktionale Sicherheit von Fahrwerkregelsystemen. Von 1996 bis 2003 war er bei der BMW AG in der Fahrzeugforschung und in der Elektronikentwicklung als Projektleiter u.a. verantwortlich für Fahrermodellierung, Optimierung Funktionsvernetzung und diverse Mechatronik-Methoden. Promoviert hat er 1995 an der RWTH Aachen im Bereich Schwingungstechnik.