Haben wir die Software und ihr Management im Griff?
Trends
Megatrends und Wertewandel
im Software und System Engineering
Produkt-/Code-Qualität versus Prozessqualität –
was sich zur Sicherung bewährt hat ...
Life Cycle Modelle und Prozesse
Best Practices (Modelle, Body of Knowledge, …)
Faktor Mensch im Arbeitsumfeld
Schlussfolgerungen
Freisetzung ungenutzter Reserven bei der Fertigung von HolzfaserplattenderThomas Schulz
Auch in der Holz- und Möbelindustrie wird der
Wettbewerb immer dynamischer.
Die technische Entwicklung der Betriebsmittel wie Maschinen und Anlagen verläuft
zunehmend schneller und die Produktlebenszyklen erkürzen sich drastisch. Je mehr der Handlungs- und Entscheidungsdruck wächst, desto dringender erwartet das Management, dass es bei den wichtigen Führungsentscheidungen mit allen relevanten Informationen aus dem aktuellen Fertigungsprozess unterstützt wird.
Welche Kriterien müssen Sie bei der Auswahl einer ERP-Software beachten? Vor der Entscheidung für ein neues ERP-System stehen meist mehrere Lösungen auf dem Prüfstand. Mit unserer ERP- Auswahlhilfe geben wir Ihnen neun Kriterien an die Hand, auf die Sie bei der Evaluierung achten sollten.
Erfahren Sie welche Kriterien sie bei der Auswahl einer ERP-Software beachten müssen.
Usability Engineering in Medizintechnik-Projektenm3mitsuppe
Die Einführung eines gebrauchstauglichkeitsorientierten Entwicklungsprozesses nach EN 62366 erfordert eine Koordination der Tätigkeiten des Usability Engineering mit denen des Software Engineering und des Requirements Engineering. Die Zusammenarbeit dieser Disziplinen birgt neben vielen Chancen auch ein Konfliktpotential.
Dieser Vortrag berichtet über typische Quellen solcher Konflikte, z.B. zwischen dem Bestreben nach einer weitgehend entkoppelten Softwarearchitektur und der Anforderung an die Bedienoberfläche, komplexe und variable Handlungsabläufe der Benutzer optimal zu unterstützen.
Im Anschluss werden in der Praxis erprobte Lösungsmuster zur Entschärfung dieser Konflikte präsentiert. Kernpunkte sind ein früher Einstieg in die Anforderungserhebung und ins Usability Engineering; die frühe und häufige Kommunikation zwischen allen Disziplinen; ein konsequent iterativer Entwicklungsprozess; sowie im Usability Engineering die Nutzung von Repräsentationsformen mit einem der jeweiligen Projektphase angemessenen Abstraktionsniveau.
Reißt Sie Ihre Software förmlich "vom Hocker"? Messen Sie das unmessbare und vermeiden Sie das Scheitern Ihres Softwareprojekts. - Leopold Peneder (HC Solutions)
Haben wir die Software und ihr Management im Griff?
Trends
Megatrends und Wertewandel
im Software und System Engineering
Produkt-/Code-Qualität versus Prozessqualität –
was sich zur Sicherung bewährt hat ...
Life Cycle Modelle und Prozesse
Best Practices (Modelle, Body of Knowledge, …)
Faktor Mensch im Arbeitsumfeld
Schlussfolgerungen
Freisetzung ungenutzter Reserven bei der Fertigung von HolzfaserplattenderThomas Schulz
Auch in der Holz- und Möbelindustrie wird der
Wettbewerb immer dynamischer.
Die technische Entwicklung der Betriebsmittel wie Maschinen und Anlagen verläuft
zunehmend schneller und die Produktlebenszyklen erkürzen sich drastisch. Je mehr der Handlungs- und Entscheidungsdruck wächst, desto dringender erwartet das Management, dass es bei den wichtigen Führungsentscheidungen mit allen relevanten Informationen aus dem aktuellen Fertigungsprozess unterstützt wird.
Welche Kriterien müssen Sie bei der Auswahl einer ERP-Software beachten? Vor der Entscheidung für ein neues ERP-System stehen meist mehrere Lösungen auf dem Prüfstand. Mit unserer ERP- Auswahlhilfe geben wir Ihnen neun Kriterien an die Hand, auf die Sie bei der Evaluierung achten sollten.
Erfahren Sie welche Kriterien sie bei der Auswahl einer ERP-Software beachten müssen.
Usability Engineering in Medizintechnik-Projektenm3mitsuppe
Die Einführung eines gebrauchstauglichkeitsorientierten Entwicklungsprozesses nach EN 62366 erfordert eine Koordination der Tätigkeiten des Usability Engineering mit denen des Software Engineering und des Requirements Engineering. Die Zusammenarbeit dieser Disziplinen birgt neben vielen Chancen auch ein Konfliktpotential.
Dieser Vortrag berichtet über typische Quellen solcher Konflikte, z.B. zwischen dem Bestreben nach einer weitgehend entkoppelten Softwarearchitektur und der Anforderung an die Bedienoberfläche, komplexe und variable Handlungsabläufe der Benutzer optimal zu unterstützen.
Im Anschluss werden in der Praxis erprobte Lösungsmuster zur Entschärfung dieser Konflikte präsentiert. Kernpunkte sind ein früher Einstieg in die Anforderungserhebung und ins Usability Engineering; die frühe und häufige Kommunikation zwischen allen Disziplinen; ein konsequent iterativer Entwicklungsprozess; sowie im Usability Engineering die Nutzung von Repräsentationsformen mit einem der jeweiligen Projektphase angemessenen Abstraktionsniveau.
Reißt Sie Ihre Software förmlich "vom Hocker"? Messen Sie das unmessbare und vermeiden Sie das Scheitern Ihres Softwareprojekts. - Leopold Peneder (HC Solutions)
Erstellung von mobilen cross-platform-AppsRalf Lütke
Mobile Apps für iOS und Android, cross-plattform, d.h. mit nur einer gemeinsamen Programmierung für beide Systeme:
- Was ist cross-plattform?
- Technologie-Vergleich und Empfehlung!
- Gegenüberstellung von Web-Apps (mit HTML5/CSS3), Hybrid-Apps (mit PhoneGap) und nativen Apps (cross-plattform mit Titanium und plattform-spezifisch mit Objective-C / Java).
"Definiere oder Du wist definiert" - ein Satz, der sehr philosophisch klingt. Und auf den Punkt bringt, was Requirements Engineering ausmacht.
Wenn in einem Software-Projekt nicht alle Beteiligten dasselbe Verständnis der umzusetzenden Anforderungen haben, wird das Ergebnis stark von den Vorstellungen der Auftraggeber und Anwender abweichen. Gutes Requirements Engineering ist daher ein wichtiger Schlüssel zum Projekterfolg.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Intel XDK: Cross-Plattform Entwicklung – Apps Entwickeln für alle Plattformen...Gregor Biswanger
Hier lernen Sie die vielfältigen Möglichkeiten der App-Entwicklung für alle gängigen Plattformen mit nur einer Programmiersprache kennen. Sie steigen mit den Grundlagen des Intel XDK ein und werden dann mit den wichtigsten Frameworks und Vorgehensweisen vertraut. Mit diesen Infos steigen Sie rasch auf zum versierten App-Entwickler und -Designer.
Umsetzungsstrategien für Cross-Plattform Projekte - IA Konferenz 2013 Klaus R...Klaus Rüggenmann
Die Festlegung auf eine technische Umsetzungsstrategie hat direkte Auswirkungen auf die Konzeption und das Design, und zwar entweder durch die sich ergebenden Einschränkungen oder durch zusätzliche Möglichkeiten. Der Vortrag will aufzeigen, welche Umsetzung für welche Art von Projekt geeignet ist. Er soll eine Entscheidungshilfe bieten und dazu befähigen, sich bei dieser zentralen Projektentscheidung informiert einzumischen.
Was macht Projekte erfolgreich? Warum scheitern Projekte und liefern nicht das, was ihre Auftraggeber erwarten? Nach wie vor ist unzureichendes Requirements Engineering der Hauptgrund für abgebrochene Projekte oder solche, die ihre Ziele nicht erreichen. Technologische Herausforderungen sind per se keine wichtigen Projektrisiken, ihr Management dagegen schon. Doch es gibt auch genügend Projekte, die ihre Ziele erreichen. Grund genug, sich mit den Praktiken des Requirements Engineering auseinanderzusetzen und wesentliche Praxistipps zu geben. Dieser Übersichtsbeitrag basiert teilweise auf dem Buch „Systematisches Requirements Engineering“, das im Dpunkt-Verlag erschienen ist [1]. Unsere Erfahrungen in verschiedenen Industrieprojekten aus einer Vielzahl von Systemen und Anwendungen zeigen, dass ein gutes Verständnis sowie eine systematische Behandlung von Anforderungen erfolgskritisch sind. Wir zeigen mit praktischen Beispielen und einem Praxisbeispiel aus ei-ner sicherheitsrelevanten Anwendung z. B. aus der Medizintechnik, wie Requirements Engineering konkret und erfolgreich umgesetzt wird. Damit können die Kosten für Nacharbeiten um ca. 30% gesenkt werden.
Service-orientierte Architekturen (SOA)
versprechen Unternehmen IT-Systeme,
die sich leicht an geänderte Geschäftsprozesse
anpassen lassen. Aufgrund dieser
Verheißungen beginnen viele Unternehmen
sich mit dem Thema SOA zu beschäftigen.
Der Studiengang Electronic
Business führte ein SOA-Integrationsprojekt
der Software AG durch. Zielvorgabe
war die Modernisierung eines Legacy Systems.
Auf Basis einer Service-orientierten
Architektur wurde für ein fiktives Reisebüro
ein Online-Buchungssystem erstellt. Dabei
wurden die technischen Möglichkeiten und
Leistungsfähigkeit der Werkzeuge der
Software AG auf den Prüfstein gestellt.
Der stetige Anstieg der Datenmenge in der heutigen Zeit stellt in der Praxis eine technisch hohe Herausforderung dar, und nicht alle Datenbanksysteme sind dafür gleich gut geeignet. Dies wurde an der Hochschule Mannheim in einem Unternehmens-Informatik-Projekt untersucht. Ausgangspunkt war eine Anwendung, die beim Aggregieren und Pivotieren der Datensätze nicht die gewünschte Performance von Antwortzeiten im Sekundenbereich lieferte. Durch die Evaluation von zwölf alternativen Datenbanktechnologien wurde zunächst eine Vorauswahl von vier geeigneten Systemen getroffen: Die spaltenbasierten Datenbanken HBase und Cassandra, sowie die dokumentenbasierten Datenbanken Mongo¬DB sowie Couchbase. Im Detail wurden die Kriterien Installationsaufwand, Performance, Skalierbarkeit und Benutzungsfreundlichkeit untersucht. HBase wird nicht für den Einsatz empfohlen; die übrigen drei Produkte und Technologien sind vielversprechend.
Open Source Business Applications im Mittelstand – Architektur und Einsatz de...Michael Groeschel
Ziel der Einführung des Open Source CRM-Systems vtiger 5.0.3 bei Kenngott International war es, die heterogene Vorgehensweisen der Vertriebspartner im Ausland zu vereinheitlichen und Kenngott durch eine Zentralisierung der Aktivitäten eine bessere Übersicht über ihr international agierendes Partnernetzwerk zu gewähren. Dazu wurde die Software vtiger erfolgreich an die speziellen Anforderungen im Unternehmen angepasst und weitere Werkzeuge entwickelt, um den Automati-sierungsgrad zu erhöhen.
Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...Michael Groeschel
Als Technologie aus dem Bereich des Geschäftsprozessmanagements rekonstruiert und analysiert Process Mining Geschäftsprozesse auf Basis digitaler Spuren in IT-Systemen. Im Gegensatz zur herkömmlichen Geschäftsprozessanalyse wird beim Process Mining ein Prozessmodell automatisch auf Basis sogenannter Event-Logs generiert. Man erhält einen detaillierten Gesamtüberblick über alle Prozessinstanzen. Mögliche Engpässe im Prozessablauf können in der Analyse aufgedeckt werden. Bei dem hier beschriebenen Projekt wurde ein Change-Management-Prozess in Kooperation mit der MLP Finanzdienstleistungen AG analysiert. Die gängigsten Werkzeuge wurden eingesetzt und einem ausführlichen Toolvergleich unterzogen.
In drei ihrer Werke arbeitet die Scherdel-Gruppe mit einer MES-Software, die in der Drahtbranche
verbreitet ist. Ein Roll-out in weitere der 29 Betriebsstätten ist geplant. Das Unternehmen legt Wert auf
solide Entscheidungsgrundlagen für die kontinuierliche Optimierung seiner Produkte. Die Flexibilität in der
Fertigung ist gestiegen.
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...Thomas Schulz
Im Jahre 1992 wurde die Manufacturing Execution Systems Association International (MESA) als Vereinigung von Entwicklern, Herstellern und Dienst leistenden Serviceunternehmen gegründet. Ziel ist es, das herkömmliche Modell eines Produktionsplanung und Steuerungssystem in Komponenten mit Blickrichtung auf eine unternehmensweite Integration aufzuteilen. Hauptsächliches Anwendungsgebiet ist die automatisierte Fertigung mit ihrer gesamten Breite und Vielfalt. Dabei werden sowohl technische, betrieblich-organisatorische als auch betriebswirtschaftlich-administrative Funktionen integriert
Erstellung von mobilen cross-platform-AppsRalf Lütke
Mobile Apps für iOS und Android, cross-plattform, d.h. mit nur einer gemeinsamen Programmierung für beide Systeme:
- Was ist cross-plattform?
- Technologie-Vergleich und Empfehlung!
- Gegenüberstellung von Web-Apps (mit HTML5/CSS3), Hybrid-Apps (mit PhoneGap) und nativen Apps (cross-plattform mit Titanium und plattform-spezifisch mit Objective-C / Java).
"Definiere oder Du wist definiert" - ein Satz, der sehr philosophisch klingt. Und auf den Punkt bringt, was Requirements Engineering ausmacht.
Wenn in einem Software-Projekt nicht alle Beteiligten dasselbe Verständnis der umzusetzenden Anforderungen haben, wird das Ergebnis stark von den Vorstellungen der Auftraggeber und Anwender abweichen. Gutes Requirements Engineering ist daher ein wichtiger Schlüssel zum Projekterfolg.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Intel XDK: Cross-Plattform Entwicklung – Apps Entwickeln für alle Plattformen...Gregor Biswanger
Hier lernen Sie die vielfältigen Möglichkeiten der App-Entwicklung für alle gängigen Plattformen mit nur einer Programmiersprache kennen. Sie steigen mit den Grundlagen des Intel XDK ein und werden dann mit den wichtigsten Frameworks und Vorgehensweisen vertraut. Mit diesen Infos steigen Sie rasch auf zum versierten App-Entwickler und -Designer.
Umsetzungsstrategien für Cross-Plattform Projekte - IA Konferenz 2013 Klaus R...Klaus Rüggenmann
Die Festlegung auf eine technische Umsetzungsstrategie hat direkte Auswirkungen auf die Konzeption und das Design, und zwar entweder durch die sich ergebenden Einschränkungen oder durch zusätzliche Möglichkeiten. Der Vortrag will aufzeigen, welche Umsetzung für welche Art von Projekt geeignet ist. Er soll eine Entscheidungshilfe bieten und dazu befähigen, sich bei dieser zentralen Projektentscheidung informiert einzumischen.
Was macht Projekte erfolgreich? Warum scheitern Projekte und liefern nicht das, was ihre Auftraggeber erwarten? Nach wie vor ist unzureichendes Requirements Engineering der Hauptgrund für abgebrochene Projekte oder solche, die ihre Ziele nicht erreichen. Technologische Herausforderungen sind per se keine wichtigen Projektrisiken, ihr Management dagegen schon. Doch es gibt auch genügend Projekte, die ihre Ziele erreichen. Grund genug, sich mit den Praktiken des Requirements Engineering auseinanderzusetzen und wesentliche Praxistipps zu geben. Dieser Übersichtsbeitrag basiert teilweise auf dem Buch „Systematisches Requirements Engineering“, das im Dpunkt-Verlag erschienen ist [1]. Unsere Erfahrungen in verschiedenen Industrieprojekten aus einer Vielzahl von Systemen und Anwendungen zeigen, dass ein gutes Verständnis sowie eine systematische Behandlung von Anforderungen erfolgskritisch sind. Wir zeigen mit praktischen Beispielen und einem Praxisbeispiel aus ei-ner sicherheitsrelevanten Anwendung z. B. aus der Medizintechnik, wie Requirements Engineering konkret und erfolgreich umgesetzt wird. Damit können die Kosten für Nacharbeiten um ca. 30% gesenkt werden.
Service-orientierte Architekturen (SOA)
versprechen Unternehmen IT-Systeme,
die sich leicht an geänderte Geschäftsprozesse
anpassen lassen. Aufgrund dieser
Verheißungen beginnen viele Unternehmen
sich mit dem Thema SOA zu beschäftigen.
Der Studiengang Electronic
Business führte ein SOA-Integrationsprojekt
der Software AG durch. Zielvorgabe
war die Modernisierung eines Legacy Systems.
Auf Basis einer Service-orientierten
Architektur wurde für ein fiktives Reisebüro
ein Online-Buchungssystem erstellt. Dabei
wurden die technischen Möglichkeiten und
Leistungsfähigkeit der Werkzeuge der
Software AG auf den Prüfstein gestellt.
Der stetige Anstieg der Datenmenge in der heutigen Zeit stellt in der Praxis eine technisch hohe Herausforderung dar, und nicht alle Datenbanksysteme sind dafür gleich gut geeignet. Dies wurde an der Hochschule Mannheim in einem Unternehmens-Informatik-Projekt untersucht. Ausgangspunkt war eine Anwendung, die beim Aggregieren und Pivotieren der Datensätze nicht die gewünschte Performance von Antwortzeiten im Sekundenbereich lieferte. Durch die Evaluation von zwölf alternativen Datenbanktechnologien wurde zunächst eine Vorauswahl von vier geeigneten Systemen getroffen: Die spaltenbasierten Datenbanken HBase und Cassandra, sowie die dokumentenbasierten Datenbanken Mongo¬DB sowie Couchbase. Im Detail wurden die Kriterien Installationsaufwand, Performance, Skalierbarkeit und Benutzungsfreundlichkeit untersucht. HBase wird nicht für den Einsatz empfohlen; die übrigen drei Produkte und Technologien sind vielversprechend.
Open Source Business Applications im Mittelstand – Architektur und Einsatz de...Michael Groeschel
Ziel der Einführung des Open Source CRM-Systems vtiger 5.0.3 bei Kenngott International war es, die heterogene Vorgehensweisen der Vertriebspartner im Ausland zu vereinheitlichen und Kenngott durch eine Zentralisierung der Aktivitäten eine bessere Übersicht über ihr international agierendes Partnernetzwerk zu gewähren. Dazu wurde die Software vtiger erfolgreich an die speziellen Anforderungen im Unternehmen angepasst und weitere Werkzeuge entwickelt, um den Automati-sierungsgrad zu erhöhen.
Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...Michael Groeschel
Als Technologie aus dem Bereich des Geschäftsprozessmanagements rekonstruiert und analysiert Process Mining Geschäftsprozesse auf Basis digitaler Spuren in IT-Systemen. Im Gegensatz zur herkömmlichen Geschäftsprozessanalyse wird beim Process Mining ein Prozessmodell automatisch auf Basis sogenannter Event-Logs generiert. Man erhält einen detaillierten Gesamtüberblick über alle Prozessinstanzen. Mögliche Engpässe im Prozessablauf können in der Analyse aufgedeckt werden. Bei dem hier beschriebenen Projekt wurde ein Change-Management-Prozess in Kooperation mit der MLP Finanzdienstleistungen AG analysiert. Die gängigsten Werkzeuge wurden eingesetzt und einem ausführlichen Toolvergleich unterzogen.
In drei ihrer Werke arbeitet die Scherdel-Gruppe mit einer MES-Software, die in der Drahtbranche
verbreitet ist. Ein Roll-out in weitere der 29 Betriebsstätten ist geplant. Das Unternehmen legt Wert auf
solide Entscheidungsgrundlagen für die kontinuierliche Optimierung seiner Produkte. Die Flexibilität in der
Fertigung ist gestiegen.
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...Thomas Schulz
Im Jahre 1992 wurde die Manufacturing Execution Systems Association International (MESA) als Vereinigung von Entwicklern, Herstellern und Dienst leistenden Serviceunternehmen gegründet. Ziel ist es, das herkömmliche Modell eines Produktionsplanung und Steuerungssystem in Komponenten mit Blickrichtung auf eine unternehmensweite Integration aufzuteilen. Hauptsächliches Anwendungsgebiet ist die automatisierte Fertigung mit ihrer gesamten Breite und Vielfalt. Dabei werden sowohl technische, betrieblich-organisatorische als auch betriebswirtschaftlich-administrative Funktionen integriert
Speaker: Michael Ferber, Head of Consulting
Über 170 Kunden setzen auf Camunda Enterprise zur Automatisierung ihrer Geschäftsprozesse. Die meisten wurden in ihren Projekten durch unsere Berater begleitet. Basierend auf diesem Erfahrungsschatz wird Michael Ferber die folgenden Fragen beantworten:
Wann macht der Einsatz von Camunda überhaupt Sinn? Welche Probleme lassen sich damit lösen?
Welche personellen Ressourcen brauche ich für erfolgreiche Camunda-Projekte?
Wie aufwendig ist die Projektumsetzung mit Camunda? Wie kann ich einen Business Case rechnen?
Measurement-Based Quality Assessment of Requirements SpecificationJakob Mund
Requirements engineering is the process of discovering, analyzing and communicating the purpose of an envisioned software-intensive system. In this thesis, we propose an approach to assess the fitness of its documented results for down-stream development (e.g., testing) based on measuring their intrinsic properties. Our results suggest that measurement-based quality assessment is no silver bullet but can provide useful estimations of certain quality aspects under specific conditions.
Artikel Netzguide: SOA als Grundlage für "Composite Applications"Peter Affolter
Das Thema serviceorientierte Architektur (SOA) ist keineswegs neu – es wurde zuerst lediglich als Hype für Web Services betrachtet. Mit «Composite Applications› können diese Services jetzt aber einfach zu neuen Applikationen orchestriert
werden.
This talk on Configuration Engineering (= Configuration Management for Platform development) will discuss challenges, solution approaches and engineering experiences in invitro-diagnostic (IVD) product development. CE is an emerging discipline in various industries (such as medical devices, automotive, avionics/ space, …) which has developed from Configuration Management practices for single products. Further, examples presented will highlight the underlying CE concepts as well as address tool issues including observed benefits over the introduction.
Configuration Engineering for Invitro-Diagnostic (IVD) Product DevelopmentArnold Rudorfer
This talk on Configuration Engineering (= Configuration Management for Platform development) will discuss challenges, solution approaches and engineering experiences in invitro-diagnostic (IVD) product development. CE is an emerging discipline in various industries (such as medical devices, automotive, avionics/ space, …) which has developed from Configuration Management practices for single products. Further, examples presented will highlight the underlying CE concepts as well as address tool issues including observed benefits over the introduction.
Configuration Engineering for Invitro-Diagnostic Product DevelopmentArnold Rudorfer
This talk on Configuration Engineering (= Configuration Management for Platform development) will discuss challenges, solution approaches and engineering experiences in invitro-diagnostic (IVD) product development. CE is an emerging discipline in various industries (such as medical devices, automotive, avionics/ space, …) which has developed from Configuration Management practices for single products. Further, examples presented will highlight the underlying CE concepts as well as address tool issues including observed benefits over the introduction.
S Ra P A Concurrent, Evolutionary Software Prototyping ProcessArnold Rudorfer
This paper defines a highly concurrent, software rapid prototyping
process that supports a sizable development team to develop a
high-quality, evolutionary software prototype. The process is particularly
aimed at developing user-interface intensive, workflow-centered
software. The Software Engineering Department and User Interface Design
Center at Siemens Corporate Research (SCR) have successfully
practiced this process in prototyping a healthcare information system
over the last year. We have evolved this agile, iterative software development
process that tightly integrates the UI designers and the software
developers with the prototype users (e.g., marketing staff), leading to efficient
development of business application prototypes with mature user
interfaces. We present the details of our process and the conditions that
make it effective. Our experience with this process indicates that prototypes
can be rapidly developed in a highly concurrent fashion given a
stable prototyping software architecture and access to readily available
domain knowledge.
People And Project Management Issues In Highly Time Pressured Rapid Prototypi...Arnold Rudorfer
This paper reports the experiences on people- and project management issues and how they
were successfully addressed to produce successive rapid deliveries of a medical healthcare
software prototype, the Soarian Financial product vision. The key practices of people and project
management are highlighted and concrete examples are provided to indicate how problems could
be resolved. Also, an outlook towards further research on people and project management issues
are presented in the context of evolutionary rapid development.
Using Evolutionary Prototypes To Formalize Product RequirementsArnold Rudorfer
Boundary objects are artifacts that facilitate
communication and interaction between people or groups
functioning in different domains. Software engineers, user
interface designers and usability specialists have different
domain knowledge, different terminologies, and shared
terms with different, distinct meanings. Boundary objects
can help assist the process of designing software by
providing a common interface for communication between
professionals in different domains. The Software
Engineering department and User Interface Design Center
at Siemens Corporate Research used an evolutionary
prototype as a boundary object to help elicit product
requirements from their client, Siemens Medical Solutions.
This enhanced communication with the client and between
groups at SCR. This paper describes how the evolutionary
prototype functioned as a boundary object and how it
allowed software engineering processes and humancomputer
interaction methods to proceed concurrently
without the need for well-defined interaction points.
This document discusses integrating user-centered design (UCD) and software engineering (SE) processes. It proposes combining the strengths of both approaches by using a single artifact, like a storyboard, to focus on client requirements, design the user interface, and shorten test cycles. The authors describe their experience developing a hospital administration software using an integrated UCD-SE process that employed a storyboard to capture requirements and verify functionality throughout development. They argue this approach can develop software faster while continually aligning with user needs.
Feature-Oriented Requirements Engineering (FORE) offers a solution to meet the challenges of engineering efficiency and cost effectiveness for medical device software development at Siemens Healthcare. FORE structures requirements according to marketable features to provide a business perspective throughout the product lifecycle. Integrating FORE provides benefits like more effective testing, transparency of requirements, reduced complexity through variability modeling, and simplified tracing. A business case found the net present value to be 15-20% of the annual R&D budget with a two year payback period, resulting in a return on investment of approximately 1:3. Testing benefits most from applying FORE.
Software-intensive medizinische Systeme stehen in einem immensen Marktdruck. Während sie technologisch und hinsichtlich ihrer Sicherheit kompromisslos innovativ sein müssen, fordern die Krankenhäuser und auch Gesundheitskostenreformen eine immer kürzere Zykluszeit bei gleichzeitig angespannten Budgets. Traditionelle Entwicklungsprozesse, die Innovation und Qualität über einen schwerfälligen Prozess erreichten, sind nicht mehr zeitgemäß. Unsere Studien zeigen, dass in der Medizintechnik die Kosten für Nacharbeiten über den Produktlebenszyklus hinweg durch eine Verbesserung des Requirements Engineering um 30-50% gesenkt werden können. Requirements Engineering hat daher eine Schlüsselstelle als Erfolgsfaktor im Gesundheitswesen. Modellbasierte Vorgehensweisen unterstützt die durchgängige Entwicklung von Anforderungen bis zur Validierung. Durch den erhöhten Abstraktionsgrad zu Beginn bei der anforderungsentwicklung und Analyse sind Problembeschreibungen wesentlich klarer, einfacher und weniger redundant. Das erhöht nicht nur die Entwicklungsgeschwindigkeit, sondern sorgt innerhalb des Projektes für klar verstandende Domänenkonzepte. Modelle helfen bei der Durchgängigkeit von den systemanforderungen zu den Softwareanforderungen und dann zu Design und Validierung. Unser Beitrag zeigt Industrieerfahrungen bei Siemens Healthcare und bietet Orientierung bei der Umsetzung modellbasierter Entwicklung mit Fokus auf Requirements Engineering in medizinischen Systemen. Wir zeigen, wie Anforderungen so formalisiert werden, dass einerseits informell formulierte Anforderungen schrittweise in eine formalere Form kommen und während die Verständlichkeit der Anforderungen erhalten bleibt. Damit sind die Anforderungen präzise formuliert und werden zur Konsistenzsicherung und Vervollständigung genutzt, und sie können weiterhin von Stakeholder verschiedenem Hintergrund verstanden und validiert werden.
Quality Re Pres Ebert Rudorfer Med Conf2011 V5Arnold Rudorfer
This document discusses quality requirements engineering for medical systems. It provides an overview of quality requirements engineering challenges for medical device projects. It then discusses Siemens and Vector Consulting, the business environment for medical devices, and examples of applying quality requirements engineering for security. The document outlines some case studies and results, concluding that quality requirements engineering can improve system reliability and availability while reducing engineering effort.
Quality Re Pres Ebert Rudorfer Med Conf2011 V4Arnold Rudorfer
This document summarizes a presentation on quality requirements engineering for medical systems. It discusses the challenges of developing safety and security critical medical devices. It provides an overview of quality requirements engineering and examples of how it was applied to a large medical device project at Siemens Healthcare involving thousands of requirements and hundreds of developers. The presentation outlines issues addressed through solutions like a feature model, forced ranking, architecture mapping, and a quality tree. It discusses positive results like improved reliability and reduced review efforts.
The document discusses applying lean approaches to requirements engineering for the syngo.via medical platform project at Siemens. It aimed to address challenges of large project scope, tight regulations and costs, and complexity growth. The project involved over 5,000 requirements, millions of lines of code, and hundreds of developers. Lean requirements engineering techniques were used to help cope with these challenges and improve results and benefits.
The document discusses challenges in product development at Siemens Healthcare and lessons learned for managing people and projects. It emphasizes the importance of multi-disciplinary teams, closed-loop communication, performance evaluations, training, and setting miniature milestones to help ensure on-time delivery of projects. Concurrent rapid prototyping is presented as an agile approach for developing products to meet tight deadlines.
The document discusses applying lean approaches to requirements engineering for the syngo.via medical platform project at Siemens. It aimed to address challenges of developing a large software project with thousands of requirements across many locations within tight budgets and regulations. The project sought to introduce lean requirements engineering techniques to help cope with these challenges and improve results.
The document discusses requirements engineering (RE) challenges at large scales and within Siemens Healthcare. It describes Siemens Healthcare's global presence and divisions. The Requirements Engineering Global Technology Field (RE GTF) was created to address RE challenges through a reference approach and centers of competence. The RE GTF provides best practices, Siemens-specific assets, and high productivity technologies to manage complexity and help projects succeed.
This document discusses model-based engineering approaches used by Siemens Healthcare in developing medical device software. It identifies challenges such as ambiguous specifications, complex architectures, and lack of verification and validation efficiency. Siemens addresses these issues through solutions like a requirements engineering meta-model to provide structure and traceability between business needs and technical specifications. They also use feature models and graphical clinical workflow models to improve understanding, scoping, and impact analysis for large projects. The aim is to increase efficiency, quality and productivity in medical device development.
This document summarizes an presentation on agile requirements engineering for a large platform project. It discusses the challenges of traditional requirements engineering for large projects. It then describes solutions implemented at Siemens Healthcare including using a feature model to group requirements, value-based prioritization of features, and incremental requirements engineering. Graphical modeling of clinical workflows was also used to improve specification clarity and reduce review times. The changes resulted in reduced effort for tracing, testing and other activities with an estimated positive net present value.
The document discusses experiences with lean requirements engineering approaches applied to a large medical platform project between Siemens and Vector. It outlines several business challenges for the project, including controlling a complex architecture and facilitating market valuation. It then describes various lean solutions applied, such as using a feature model to group requirements, value-based ranking of features, mapping features to architecture, modeling clinical workflows visually, and adopting agile development practices. Structure-based tracing of features and requirements is also proposed to reduce tracing efforts and errors.
The document describes a presentation given by Siemens Healthcare SYNGO on their experiences using Microsoft Team Foundation Server (TFS). The presentation covered SYNGO's rationale for adopting TFS, how they set up their TFS program, initial experiences with project and change management using TFS, best practices for usability when customizing TFS, and the pros and cons they have identified with using TFS. The presentation was intended to provide an overview of SYNGO's TFS program and lessons learned from their experience transitioning to TFS for development project management.
2. { REQUIREMENTS-ENGINEERING
Bedeutung zu. Nur, wenn alle sicherheitsrelevanten
Zusammenfassung Anforderungen sauber erfasst werden, kann sicher-
Requirements-Engineering zielt auf die sys- gestellt werden, dass von diesem System keine Ge-
tematische Erhebung der Anforderungen für fährdung ausgeht, alle Risiken bedacht sind und über
ein zu entwickelndes Produkt oder System die Anforderungen entsprechend adressiert werden.
auf Basis genereller Geschäftsziele und Vor- Zahllose Probleme mit Systemen mit hohen
gaben ab. Angestrebt werden dokumentierte Softwareanteilen haben aus Sicht der Benutzer
Anforderungen an Produkte oder Systeme, die oft nicht mit der Frage zu tun, ob Anforderungen
optimal nutzbar und vermarktbar sind und in korrekt umgesetzt werden, was durch Verifikation
jeder Hinsicht möglichst gut den Erwartungen nachgewiesen wird, sondern betreffen eher den
aller Beteiligten entsprechen. Bedingt durch Punkt, dass die Anforderungen nicht im Sinne der
den hohen Innovationsgrad bei Software oder Nutzer angemessen festgelegt sind. Die berühmte
Produkten mit hohem Softwareanteil und den Frage ,,Is it a bug or a feature?“ hat nur zu oft ihre
steigenden Ansprüchen in Hinblick auf Funktio- Ursache in der ungenügenden Festlegung der An-
nalität kommt dem Requirements-Engineering forderungen. Wenn Systeme unerwartet und damit
eine Schlüsselstellung im Software und Systems aus Sicht der Nutzer fehlerhaft reagieren, handelt es
Engineering zu. Vor diesem Hintergrund hat die sich eben nicht immer um Implementierungsfehler,
Technische Universität München und Siemens bei denen die Spezifikation nicht korrekt umgesetzt
Corporate Research in Princeton, USA, ein ist, sondern allzu häufig auch um eine Diskrepanz
Requirements-Engineering–Referenzmodell zwischen dem, was der Nutzer erwartet und dem,
(REM) entwickelt, das Struktur und Inhalte der was die Spezifikation festgelegt hat.
Ergebnisse (,,Artefakte“) des Requirements- Untersuchungen zeigen, dass der Stand und
Engineering vorgibt. Es ist durch ,,Tailoring“ die Beherrschung des Requirements-Engineering
auf unterschiedliche Anwendungsdomänen und in der Praxis unbefriedigend sind. Vor diesem Hin-
Dokumentenvorgaben zuschneidbar. Es unter- tergrund sind die Technische Universität München,
stützt iterative Prozesse und eine modellbasierte vertreten durch den Lehrstuhl für Software und
Entwicklung. Systems Engineering, und die Siemens AG, vertreten
Der Ansatz REM wurde bereits erfolgreich durch Siemens Corporate Research Princeton, seit
zur Analyse und Bewertung durchgeführter Ent- einigen Jahren eine langfristige strategische Zusam-
wicklungsprozesse eingesetzt. Hierzu wurden menarbeit zum Thema Requirements-Engineering
die im untersuchten Projekt erstellten Spezi- eingegangen. Das Ziel des akademischen Partners
fikationsdokumente (beispielsweise Vision- & liegt auf der Hand: Fundiertere Methoden und grö-
Scope-Dokument, Lasten- und Pflichtenhefte, ßere Systematik zum Requirements-Engineering,
Architekturdokumente, usw.) hinsichtlich der wie dies in den letzten Jahren in wissenschaftlichen
im Artefaktmodell festgelegten Inhalte und Arbeiten entwickelt wurde, stärker in die Praxis
Beziehungen analysiert und bewertet. Gemein- zu bringen. Das Ziel des industriellen Partners ist
sam mit der entsprechenden Untersuchung andererseits auch klar: Auf Basis einer Vielzahl
des eingesetzten Requirements-Management- von Erfahrungen auf diesem Gebiet und vor dem
Werkzeugkonzepts können hieraus Aussagen Hintergrund von Best-Practice-Ansätzen mithilfe
zur Vollständigkeit und Qualität der betrach- von wissenschaftlichen Beiträgen das Thema zu
teten Spezifikationsdokumente und ihres konsolidieren und in eine langfristige Zusammen-
Erarbeitungsprozesses gefolgert werden. arbeit einzutreten, um industrielle Projekte besser
unterstützen zu können.
ten Teilaspekte eines Systems erstrecken. Die Fest- Requirements-Engineering und seine
legung der Anforderungen bestimmt entscheidend wirtschaftliche Bedeutung
sowohl die Qualität als auch die Kosten eines Systems Waren die Anfänge des Einsatzes von Software
und damit auch dessen wirtschaftlichen Erfolg. in Prozessen und Produkten eher von der Auto-
In sicherheitskritischen Anwendungen kommt matisierung bekannter Funktionen geprägt, so
der Anforderungsanalyse noch eine zusätzliche bestimmen die Entwicklung und den Einsatz von
3. und welchen Beitrag es zur Bewältigung der
Abstract damit verbundenen Herausforderungen liefern
Engineering supports a systematic collection kann.
of product or system requirements regarding
business goals and constraints. The goal is to Beherrschung der wachsenden Komplexität
assure that the developed system optimally Produkte, in denen immer häufiger verteilte Sys-
meets the user and market needs. That means teme mit vielfältigen Einsatzfunktionen eingebettet
that all stakeholder expectations have been sind, werden zunehmend umfangreicher, an-
taken in consideration. With regards to the high spruchsvoller und komplexer. Sie offerieren Ihren
pace of innovation in software and software in- Nutzern reichhaltige Interaktionen mit Zugriff auf
tensive systems and also the rapidly increasing hoch innovative Funktionen (oder Features1 ). Aber
functional complexity Requirements Enginee- oft kommt es zur sogenannten ,,Software Pollution“
ring excellence is now a critical success factor und zum ,,Over Engineering“, siehe Abb. 1. Das
in product and system development. In this heißt, das Produkt umfasst weit mehr Funktionen
context the Technical University Munich and als der Nutzer und damit der Markt wirklich benö-
Siemens Corporate Research are cooperating tigt. Häufig sind auch mehr Features implementiert
in developing a Engineering Reference Model als tatsächlich ausgeliefert werden: Zum einen, um
(REM) that defines the structure and content of für eventuelle zukünftige Benutzeranforderungen
the results (“artifacts”) of Requirements Engi- gerüstet zu sein und zum anderen, weil die aktu-
neering activities. It includes a tailoring concept ellen Anforderungen zu vage formuliert sind und
that allows its adaptation to different application deshalb mit weiteren Funktionen experimentiert
domains and documentation constraints. REM wird.
supports iterative processes and model based Dies zeigt, dass ein Großteil der zunehmenden
development. Komplexität hausgemacht und damit vermeid-
bar ist. Allerdings ist hierzu ein professionelles
Requirements-Engineering nötig, insbesondere
Software immer stärker auch innovative Funktionen. ein wohl definierter Erhebungsprozess und eine
Diese erfordern zwangsläufig einen Lernprozess Methodik zur Bestimmung des ,,Geschäftswertes“
in Hinblick auf die wesentlichen funktionalen einer Funktion oder Anforderung. Eine Methodik,
und nichtfunktionalen Anforderungen. Damit die die Priorisierung der Anforderungen bezüglich
kommt dem Requirements-Engineering eine immer ihres Geschäftsnutzens unterstützt, garantiert nur
tragendere Rolle zu. die Implementierung der wesentlichen Anforde-
rungen. Um sicherzustellen, dass auch wirklich
Trends in der Industrie nur diese Features implementiert werden, müssen
Drei große Trends und die damit verbundenen diese Anforderungen über den Entwicklungsprozess
Herausorderungen bestimmen heute unter anderem verfolgt und entsprechende Testfälle erstellt werden,
die industrielle Fertigung von Produkten ebenso wie um die Minimalität der Entwicklung sicherstellen zu
die Entwicklung komplexer Systeme wie Verkehrs- können.
leitsysteme, Computertomografien, Autoelektronik,
Automatisierungssysteme oder Systeme für den Neue Funktionalitäten –
Energiebereich. Software als Innovationstreiber mit
Diese aktuellen Trends sind: immer kürzeren Innovationszyklen
In den vergangenen Jahren ist der Anteil von
· stark wachsende Komplexität der Produkte, Software in Produkten, Dienstleistungen und Sys-
· Software als Innovationstreiber, folglich immer kürzere temlösungen kontinuierlich gewachsen. Bei Siemens
Innovationszyklen und beträgt der Softwareanteil in der Produkt- und
· voranschreitende Globalisierung mit verteilter Entwicklung. Lösungsentwicklung heute schon (schätzungsweise)
mehr als 60%.
Im Folgenden zeigen wir kurz die Rolle des
Requirements-Engineering für diese Trends 1 Ein Feature ist eine Gruppe von Produktfunktionen.
4. { REQUIREMENTS-ENGINEERING
Abb. 1 Software Pollution [10]
Produktinnovationen werden zu einem stark in allgemeine und Zielgruppen oder marktspe-
wachsenden Teil in Softwarekomponenten rea- zifische Anforderungen erforderlich, sowie ein
lisiert. 50% der Produkte, Dienstleistungen und entsprechender Prozess, der alle Beteiligten von
Systemlösungen bei Siemens sind jünger als fünf der Unternehmensführung, über Vertrieb, Marke-
Jahre. In Hochtechnologiebranchen wie etwa der der ting, Produktmanagement bis zur Entwicklung mit
Medizintechnik sind 90% der Produkte sogar jünger einschließt.
als drei Jahre. Eine weitere Dimension der Globalisierung
Bei diesen extrem kurzen Innovationszyklen ist ist die zunehmende verteilte Entwicklung das Off-
ein effizientes und systematisches Requirements- shoring in Niedriglohnländer. Beides erhöht die
Engineering mit einem wohl definierten Übergang Anforderungen an das Requirements-Engineering
von innovativen Produktideen in den Realisie- enorm, da all die informellen Kommunikationswege
rungsprozess unabdingbar. Falls Missverständnisse wegfallen und zusätzlich kulturelle Differenzen die
und Unklarheiten der Produktanforderungen in Kommunikation erschweren.
den frühen Phasen nicht beseitigt werden können,
führen diese zu einem stark erhöhtem Aufwand in Requirements-Engineering in der Praxis
der Produktrealisierung und im schlimmsten Fall Unter Requirements-Engineering verstehen wir das
zum Scheitern des Produkts, wenn es am Markt Erfassen, Analysieren, Entwickeln, Strukturieren
vorbeientwickelt wird. und Dokumentieren von Anforderungen und Lö-
sungskonzepten. Wesentliche Aufgaben sind hierbei
Voranschreitende Globalisierung das Validieren und Abstimmen verschiedener,
Die Industrie entwickelt heute nicht mehr nur für möglicherweise widersprüchlicher Aspekte der
lokale Märkte sondern für den Weltmarkt. Doch der Produktentwicklung und die entsprechende Priori-
Weltmarkt besteht aus vielen lokalen Märkten, die sierung und Entscheidung über Anforderungen und
ihre spezifischen Anforderungen haben. zu realisierende Produktfunktionen.
Um auf diesem Weltmarkt bestehen zu können, Requirements-Engineering umfasst:
müssen die Produkte und Lösungen adaptierbar
und auf die Anforderungen der lokalen Märkte ab- · die Identifikation aller Lebenszyklus-Aktivitäten mit dem
gestimmt sein. Für die technologische Realisierung Ziel, Geschäfts- und Anwenderanforderungen zu gewinnen,
leicht adaptierbarer Produkte müssen jedoch die · die Identifikation von Anforderungen und Randbe-
Anforderungen systematisch analysiert, die Gemein- dingungen abgeleitet aus der Zielumgebung und
samkeiten herausgearbeitet und von den variablen Realisierungstechnologien,
Anforderungen separiert werden. Gleiches gilt für · die Analyse von Anforderungen und Ableitung detaillierter
unterschiedliche Nutzergruppen und Zielmärkte. zusätzlicher Anforderungen,
Hierfür ist eine systematische Methodik zur · die Dokumentation und Management von Anforderungen
Erfassung und Unterscheidung der Anforderungen und Spezifikationen,
5. · die Validierung und Verifikation der dokumentierten mentierbar und nicht skalierbar strukturiert. Verfügbare
Anforderungen gegen die Nutzerbedürfnisse, Werkzeuge sind sehr ineffektiv, bieten nur sehr generi-
· ein intuitives und eindeutiges Medium zur Kommunikation sche Konzepte, sind zu implementierungsnah, fordern
der Produkt- und Funktionalitätsideen zwischen Anwendern hohen Administrationsaufwand und bieten schlechte
und Entwicklern, Visualisierungskonzepte an.
· die Entwicklung innovativer Produktkonzepte, welche oft · Zwischen Produktmanagement, Forschung & Ent-
durch Software ermöglicht werden und wicklung, Marketing und Vertrieb gibt es keine klar
· die Verwaltung und Instandhaltung der Produktanforde- abgestimmten Vorgehensweisen und kein einheitliches
rungen von der Auslieferung bis zur Abkündigung. Kommunikationsmedium.
· Häufige und späte Änderungen der Anforderungen sind
Bedeutung von Requirements-Engineering nicht vermeidbar und werden insbesondere bei Prozessen
im Entwicklungs-Life-Cycle mit sequenziellen Vorgehensweisen nicht ausreichend
Industriestudien zum Thema Requirements-Engin- beherrscht. Änderungsraten von 2–3% pro Monat [13] sind
eering (RE) zeigen auf, wie stark der Einfluss von nicht untypisch.
RE auf den Projekterfolg ist. So weist der Standish
Report [9, 30] nach, dass mehr als 50% der ,,Schlüs- Industrielle Programme
selfaktoren“ für einen Projekterfolg im Require- Um den genannten Herausforderungen in der Sys-
ments-Engineering zu finden sind. Wingrove, Wie- tementwicklung zu begegnen und die identifizierten
gers und Gottesdiener schätzen, dass 40% bis 60% Schwachstellen im Requirements-Engineering zu
aller Produktdefekte im Requirements-Engineering beheben, wurden in betroffenen Unternehmen sys-
ihren Ursprung haben [14, 33, 34]. tematische Verbesserungsmaßnahmen initiiert. Die
Schon länger unbestritten ist, dass eine frühe Siemens AG hat wie auch Alcatel [13] und Intel [25]
Fehlerfindung durch eine stärkere Fokussierung auf ein Programm zur Verbesserung des Requirements-
die frühen Entwicklungsphasen insgesamt zu einer Engineering für Projekte aufgesetzt. Innerhalb
Kostenreduktion führt. Barry Boehm hat bereits von Siemens ist Siemens Corporate Research für
darauf hingewiesen, dass Fehlerkorrekturen in die Ausgestaltung des Requirements-Engineering-
den frühen Phasen 50 bis 200 mal billiger sind als Programms verantwortlich. Es ist organisatorisch
wenn das Produkt im Feld ist [4]. Steve McConnell mit dem unternehmensweiten top+ Programm
ermittelte Faktoren zwischen 10 und 100 in seinen assoziiert. Das Ziel ist Exzellenz im Requirements-
Arbeiten [23]. Engineering und soll durch folgende Maßnahmen
Capers Jones untersuchte die Zeitaufwände für erreicht werden:
das überarbeiten der Requirements-Engineering-
Defekte mit einem Ergebnis von 40% bis 50% des · Zur Verfügung stellen und Entwickeln von ,,state-of-the-art“-
gesamten Projektaufwandes [19, 20]. Requirements-Prozessen, Methoden, Tools und Metriken –
insbesondere für spezifische Geschäftsdomänen.
Schwächen heutiger · Einbettung von Requirements-Engineering in die Siemens-
Requirements-Engineering-Praxis Geschäftsprozesse (Produktmanagement, Marketing,
Capers Jones stellte in seiner Untersuchung fest, dass Innovation Management etc.).
die Requirements-Engineering-Disziplin in mehr als · Aufbau von Trainings- und Zertifizierungsangeboten für die
75% aller Unternehmen nur sehr mangelhaft durch- Mitarbeiter.
geführt wird [19, 20]. Seine Ergebnisse machen
deutlich, dass ein großes Verbesserungspotenzial Das Programm ist auf sechs Säulen aufgebaut
vorhanden ist. Aufbauend auf seine Kategorisie- (s. Abb. 2), um obige Zielsetzung auch umfassend
rung sehen wir folgende Herausforderungen als und nachhaltig umzusetzen.
besonders kritisch: Das Programm ist in die Siemens-Software-
Initiative integriert und es wurden bereits drei
· Es gibt keine eindeutige Definition, was eine ,,Best Practice“ erfolgreiche internationale Konferenzen mit Gast-
ist, letztendlich fehlen akzeptierte Referenzmodelle. rednern aus Industrie und Forschung durchgeführt.
· Die Anforderungen sind mangelhaft dokumentiert, zu Speziell für Projekteiter und Manager wurde eine
lösungsorientiert, unvollständig, inkonsistent, nicht imple- Checkliste entwickelt, die zehn kritische Erfolgs-
6. { REQUIREMENTS-ENGINEERING
faktoren für eine erfolgreiche Produktdefinition
festlegt. Sie erhebt keinen Anspruch auf Vollständig-
keit, aber wenn mehrere dieser Faktoren in einem
Projekt nicht beachtet werden, sind Probleme zu
erwarten (s. Abb. 3).
Requirements-Engineering
an der TU München (TUM)
Das Thema Spezifikation hat in Forschungsarbei-
ten der Informatik sehr früh Eingang gefunden.
Bereits in den 60er und 70er Jahren gab es eine
Fülle von Arbeiten, die gerade dem Thema der
formalen Spezifikation von Datenstrukturen und
Programmen gewidmet waren. Dazu gehören
grundlegende Arbeiten zum Thema Semantik
Abb. 2 Säulen des Siemens-Corporate-Research-Requirements- von Programmiersprachen, aber auch methodi-
Engineering-Programms [1] sche Arbeiten zur Spezifikation von Programmen
Abb. 3 Zehn kritische Erfolgsfaktoren der erfolgreichen Produktdefinition und Anforderungsanalyse [3]
7. durch Annotationen und letztlich auch Arbeiten späteren Entwurfsphasen integriertes, bewertbares,
in Verbindung mit den Ansätzen der Programm- quantifizierbares und in Teilen automatisierbares
verifikation. Diese Ansätze im Umfeld sogenannter Requirements-Engineering ist das konsequente Ein-
formaler Methoden waren aber deutlich getrennt führen von Modellen in das Requirements-Engin-
von stärker pragmatischen Überlegungen, die auch eering. Dabei handelt es sich einmal um Modelle,
mit praktischen Fragestellungen in Verbindung zu die geeignet sind, funktionale Anforderungen zu
sehen sind, wie Methoden der strukturierten Ana- beschreiben, zum anderen um Modelle, die stärker
lyse, die bereits auch diagrammatische Techniken auf Architekturen ausgerichtet sind und in einem
einsetzten, um Anforderungsanalyse zu betreiben. Zusammenhang zu nichtfunktionalen Anforderun-
In einem umfassenden Sinn wurde das Thema gen zu sehen sind, aber auch um weiterführende
Requirements-Engineering jedoch auf akademi- Modellbildungen im Zusammenhang mit Qualitäts-
scher Seite in diesen frühen Zeiten nicht behandelt. modellen und nichtfunktionalen Anforderungen.
Im Laufe der Jahre entstanden, parallel zu den Ar- Hier finden sich viele faszinierende Forschungs-
beiten der formalen Methoden, schließlich stärker fragen, die in vielerlei Hinsicht noch nicht genügend
pragmatische Ansätze zur systematischen Analyse bearbeitet sind.
und Erarbeitung von Anforderungen. Die wissen-
schaftlichen Gruppierungen zum Thema formaler Ausgangspunkt
Methoden und die Forschergruppen, die sich stärker Der Lehrstuhl für Software und Systems Engineer-
mit Requirements-Engineering als pragmatische ing der Technischen Universität München (TUM)
Aufgabenstellung beschäftigten, blieben aber im arbeitet seit langem auf dem Gebiet der formalen
Laufe der Jahre weitgehend disjunkt. Modellierung und Systemspezifikation. Ziel ist
Es zeigt sich, dass für fortgeschrittenes Require- es präzise und adäquate/brauchbare System-
ments-Engineering eine Synthese aus diesen eher beschreibungsmodelle zu entwickeln, die mit
formalen Ansätzen und den pragmatischen Vorge- entsprechenden Techniken die qualitativ höher-
hensweisen, die eine breitere Sicht auf das Require- wertige Systemdefinition unterstützen. Dies umfasst
ments-Engineering haben, erforderlich ist. Hinzu modellbasierte Methoden der Systemspezifikation,
kommen die Ideen der modellbasierten Entwick- Verifikation, Codegenerierung, Qualitätssiche-
lung, die eine konsequente Fortsetzung der Ansätze rung und Testspezifikation. Abbildung 4 zeigt
formaler Methoden sind und heute in der Praxis die Systembeschreibungsmodelle des Werkzeuges
stärker pragmatisch eingesetzt werden. Ein Ziel für AutoFocus [2, 5, 36]. Es ist ein modellbasiertes Ent-
ein stärker werkzeugunterstütztes, besser in die wicklungswerkzeug für den Entwurf eingebetteter
Abb. 4 Grafische Systembeschreibungstechniken in AutoFocus
8. { REQUIREMENTS-ENGINEERING
Systeme. Es verbindet Konzepte der Design- beitung von modellbasierten Methoden schrittweise
Modellierung, der Simulation sowie der Code- und REM hinzuzufügen.
Testfallgenerierung, und erlaubt die Verifikation
von Software-Komponenten. Die mathematisch Requirements-Engineering-
fundierten2 Systemsichten mit ihren grafischen Referenzmodell (REM)
Beschreibungstechniken sind (s. Abb. 4): Ausgangspunkte für die Entwicklung von REM
waren die Forschungsaktivitäten der TUM sowie
· hierarchische Strukturdiagramme (SSDs), Erfahrungen und Projekte der Siemens Corporate
· Zustandsautomaten (STDs), Research (SCR) in Princeton, USA und Siemens
· erweiterte Sequenzdiagramme (EETs) und Corporate Research & Technology (CT) in Mün-
· Datentypdefinitionen (DTDs). chen. Die zentralen Forschungseinheiten haben die
Aufgabe, die Siemens-Geschäftsbereiche durch Best-
Nachdem der Schwerpunkt bisher auf der Practice-Sharing und Innovation in diesem Bereich
präzisen und angemessenen Spezifikation des er- zu unterstützen.
forderlichen Systemverhaltens lag, geht man jetzt
dazu über modellbasierte Methoden auch in der Zielsetzung
Kernphase des Requirements-Engineering anzu- Zielsetzung von REM ist die Unterstützung und
wenden, bis hin zu ihrem systematischen Einsatz zur Prozessdefinition des Requirements-Engineering
schrittweisen Konstruktion, Analyse und zielorien- (RE) auf der Basis eines grundlegenden Modells
tierten Konsolidierung von Anforderungsmodellen. zu erarbeitender Spezifikationsartefakte und ihrer
Entsprechende Grundkonzepte des modellbasierten Beziehungen. Hierzu definiert REM
Requirements-Engineering, der artefakt-zentrierten
Prozessdefinition, der Qualitätssicherung und der
· eine Kernmenge von RE Artefakten und ihren Abhängig-
keiten – das RE-Artefaktmodell – und
messbaren Entscheidungsunterstützung sind in [15]
zusammengefasst.
· ein artefakt-zentriertes Tailoring-Konzept.
Der Ansatz des Requirements-Engineering-Re- In Analogie zum V-Modell XT unterstützt dies eine
ferenzmodell (REM) [16], wie er im nachfolgenden artefakt-basierte Prozessdefinition und definiert
Abschnitt ausführlich dargestellt wird, ist ein erster Meilensteine in der Systementwicklung auf der
Schritt in Richtung auf eine Synthese zwischen Basis von zu erarbeitenden RE-Artefakten. Für die
formalen Techniken, insbesondere Modellierungs- Anwendung und Instanziierung des Ansatzes in
techniken und einem breit angelegten methodischen konkreten Projekten und Domänen ist ein Tailoring-
Ansatz zum Requirements-Engineering. Konzept definiert.
Gemeinsam mit den Erfahrungen der Siemens-
Forschung zum Requirements-Engineering und REM im Produktlebenszyklus
weiteren Vorarbeiten der TUM zu Qualitätsmodel- REM geht von folgenden Aufgaben des Require-
len [6, 11] und der artefakt-orientierten Prozess- ments-Engineering im Lebenszyklus eines Pro-
definition im V-Modell XT [35] sind diese Ansätze duktes aus. Hierzu gibt Abb. 5 einen allgemeinen
in REM umgesetzt und im Kontext komplexer Überblick über Entstehung, Einsatz und Wartung
industrieller Anforderungen präzisiert worden. eines Produktes und seiner schrittweisen Weiterent-
REM schafft hierbei zunächst ein Referenzmo- wicklung auf Basis von Kundenerfahrungen, neuen
dell, das die wesentlichen Artefakte, die als Ergebnis Marktstrategien und Technologien.
eines strukturiert angelegten Requirements-Engin- Die Aufgaben des Requirements-Engineering
eering zu erarbeiten sind, festlegen und zueinander sind hierbei:
in Beziehung setzt. Für REM existieren erste Ausprä-
gungen zum Einsatz formaler Methoden, zumindest · Marketinginformationen und Nutzeranforderungen zu
für die konstruktive Erarbeitung und qualitative analysieren, die funktionalen und nichtfunktionalen Anfor-
Überprüfung bestimmter Artefakte. In weiteren derungen abzuleiten und den entsprechenden funktionalen
Schritten ist geplant, hier eine umfassendere Ausar- Entwurf des Systems zu steuern.
· Die Auswirkungen dieser Anforderungen auf das Geschäft
2 Der strombasierte Ansatz von FOCUS [7] zur Systemmodellierung. und den Erfolg des Produktes im Markt zu verstehen.
9. Abb. 5 Der Produktentstehungsprozess im Überblick
· Diese Anforderungen abzustimmen, zu konsolidieren und der zu erarbeitenden Spezifikationsdokumente der
in einer Anforderungs- und Systemspezifikation konsistent fachübergreifenden Abstimmungsaktivitäten der
und vollständig zu spezifizieren. Produktentwicklung.
Das Modell ist nach folgenden Paradigmen
Somit hat das Requirements-Engineering eine der integrierten Anforderungsanalyse und System-
zentrale Rolle in der Produktdefinition und Ent- definition gestaltet:
wicklung. Die erarbeiteten Spezifikationsartefakte
sind die Basis für Produktdesignentscheidung · ziel- und nutzerorientierte Analyse und Verfeinerung von
und Projektmanagement während des gesamten Anforderungen und funktionalen Entwurfskonzepten,
Produktlebenszyklus. Die Qualität und Angemes- · Analyse und Verfeinerung von ,,high-level“ funktionalen
senheit der Artefakte ist ein Schlüsselfaktor für die und nichtfunktionalen Anforderungen mithilfe eines grund-
erfolgreiche Systementwicklung. legenden Beschreibungskonzeptes für Systeme und ihres
Verhaltens aufbauend auf der Modellierung funktionaler
Das Artefaktmodell Systemsichten und
REM strukturiert und gibt Vorgaben für die · qualitative Überarbeitung erarbeiteter Spezifikationen auf
Anforderungsanalyse- und Systementwurfsak- Basis definierter Beziehungen zwischen verschiedenen
tivitäten mittels eines grundlegenden Modells von Klassen von Anforderungen und Systemmodellen (RE-
Requirements–Engineering-Spezifikationspro- Artefakten) des Artefaktmodells. Diese Abhängigkeiten
dukten – dem RE-Artefaktmodell. Abbildung 6 zwischen Artefakten bilden messbare Konsistenzbe-
zeigt einen Überblick über das Modell und seine dingungen und können für die Verifikation und
Struktur. Es unterteilt die zu erarbeitenden An- Validierung erstellter Systemanforderungen genutzt
forderungen (RE-Artefakte) in die Gruppen werden.
Business-Needs, Requirements-Specification und
System-Specification. Die Artefakte mit ihren defi- Entsprechend dieser methodischen Konzepte ist die
nierten Inhalten bestimmen die Struktur und Inhalte Beschreibung der einzelnen RE-Artefakte aufgebaut
10. { REQUIREMENTS-ENGINEERING
Abb. 6 Überblick über das REM-Requirements-Engineering-Artefaktmodell
und gibt Vorschläge einzusetzender Methoden und · General Conditions und Scope & Limitations spezifizieren
Beschreibungstechniken zur Konstruktion, Kommu- ,,high-level“-nichtfunktionale Anforderungen und Beschrän-
nikation und Konsolidierung ihrer erforderlichen kungen und grenzen den relevanten Ausschnitt der Anwen-
Inhalte (Content-Items). Die weitere Unterteilung dungsdomäne und gegebenenfalls der Produktlinie ab.
der Artefakte in Content-Items wird in Abb. 7 am Bei- · Return of Investment (ROI) und Business-Risk fassen die
spiel der Requirements-Specification-Artefaktgruppe Ergebnisse mehrfacher Kosten-Nutzen-Analysen, erwartete
demonstriert. Verkaufserlöse, Entwicklungs- und Markteinführungskosten
zusammen und stellen die entsprechende Risikoanalyse von
Artefaktgruppen Anforderungen in den Mittelpunkt.
· System-Success-Factors spezifizieren und priorisieren die
Business-Needs-Artefakte Kriterien für den finalen Produkterfolg.
Die Business-Needs-Artefakte spezifizieren kunden-
und produktstrategische Anforderungen, ins- Diese Produktziele und Abgrenzung sind das Er-
besondere die Geschäfts- und Produktziele der gebnis sorgfältiger Marketing-, Portfolio- und
Systementwicklung. Zu der Gruppe gehören Kundenabstimmung. Gemeinsam mit wiederhol-
folgende Artefakte: ten Return-of-Investment- und Risikoanalysen
legen sie die Basis für die nachfolgende Ent-
· Business-Objectives und Customer-Requirements spe- wicklungsarbeit und bilden die Grundlage für
zifizieren Kundenanforderungen und beschreiben die Produktdesign-Entscheidungen.
Marktpositionierung des zukünftigen Produktes.
· System-Vision listet die geforderten funktionalen Requirements–Specification-Artefakte
Anforderungen/Features auf und legt die Planungsan- Die Requirements-Specification-Artefakte bein-
nahmen und Projektabhängigkeiten der Produkt- oder halten die funktionalen und nichtfunktionalen
Produktlinienentwicklung fest. Anforderungen an das zu entwickelnde System.
11. Abb. 7 Überblick über die Requirements-Specification-Artefakte
Mithilfe dieser Artefakte werden die Ziele und Vor- Annahmen (Assumptions & Dependencies) und Constraints
gaben der Business-Needs-Artefakte aus Kunden- (Design-Constraints) und bilden diese auf die detaillierten
und Nutzersicht analysiert, strukturiert und detail- Anforderungen der System-Specification ab.
lierte Anforderungen und Qualitätsvorgaben an das · Acceptance-Criteria spezifizieren die Abnahme- und
Nutzungserhalten des Systems abgeleitet. Zu ihnen Testkriterien des auszuliefernden Systems.
gehören diese Artefakte:
Die wesentliche Rolle der Analysemodelle der Re-
· Functional-Analysis-Models enthalten Analyse- und quirements-Specification-Artefakte ist die Verfei-
Beschreibungsmodelle der Geschäfts- und Anwendungs- nerung und Strukturierung der ,,high-level“-fest-
prozesse. Sie dienen der Kommunikation der Kunden- gelegten Business-Needs sowie ihrer Abbildung auf
und Nutzeranforderungen, der Bestimmung erforderlicher die detaillierten Systemanforderungen des entspre-
Systemdienste/Features und Qualitätseigenschaften und chenden Systementwurfskonzeptes. Sie bilden die
sie bilden die Basis für die Evaluierung und Bewertung Entscheidungsbasis für die Priorisierung von Anfor-
erarbeiteter System-Specifications. derungen und ermöglichen begründete und nach-
· Domain-Models sind eine strukturierte Spezifikation der vollziehbare Produktdesignentscheidungen. Zuge-
Anwendungsdomäne und ihrer Charakteristika und wer- schnitten auf domän- und projektspezifische Erfor-
den ergänzt durch eine Modellierung der operationellen dernisse können hier passende Methoden und Be-
Umgebung des zukünftigen Systems. schreibungstechniken für die Erarbeitung und Ab-
· Nichtfunktionale Anforderungsmodelle verfeinern und struk- stimmung der RE-Artefakte eingesetzt werden. Ak-
turieren Qualitätsanforderungen (Quality Requirements), tuelle Ansätze der Prozess- und Szenarioanalyse hier-
12. { REQUIREMENTS-ENGINEERING
zu sind Strukturierungsmethoden von [27, 28], der Phasen in der Produktdefinition – weniger auf den
Fraunhofer-QUASAR-Ansatz [29], AutoRAID [15, 17], konkreten Aufbau der Dokumente. Spezifikations-
die aufgabenorientierte Szenarioanalyse von [8, 31] dokumente als Basis für Meilensteinentscheidungen
und Methoden der szenariobasierten Testfallab- setzen sich aus Inhalten quer über das Artefakt-
leitung [18]. Ansätze der Ziel- und Qualitätsmodel- modell zusammen. Die spezifisch erforderlichen
lierung sind KAOS [22], ATAM [21], TROPOS [32] Dokumentstrukturen eines Entwicklungsprojektes
sowie die ASPIRE-Methode für die Konstruktion werden durch das domänenspezifische Tailoring
erfahrungsbasierter Qualitätsmodelle [12]. Das des Artefaktmodells und der daraus folgenden
grundlegende Konzept von REM, Anforderungen Prozessdefinition bestimmt.
mithilfe funktionaler Systemsichten herauszuar-
beiten und zu strukturieren (AutoRAID/Auto- Prozessdefinition und Tailoring
Focus [2, 15, 17, 36]) findet sich auch in den Ansätzen Das RE-Artefaktmodell bildet den Ausgangspunkt
von [26, 27] wieder. für das domänenspezifische Tailoring und eine
artefakt-zentrierte Prozessdefinition. REM definiert
System-Specification-Artefakte Meilensteine und Entscheidungspunkte im Produkt-
Die System–Specification-Artefakte adressieren den entstehungsprozess in Form von Vollständigkeits-
detaillierten Entwurf des funktionalen Systemkon- bzw. Qualitätsstufen auf den RE-Artefakten.
zeptes: Es spezifiziert das erforderliche Verhalten
des betrachteten Systems und seine Integration in Artefakt-basierte Prozessdefinition
das technische Gesamtsystem und die Anwendungs- Abbildung 8 zeigt dieses Konzept der artefakt-
umgebung. Zusätzlich werden die Bedingungen für zentrierten Prozessdefinition: Das Artefaktmodell
den detaillierten Entwurf und die Realisierung des definiert Inhalt und Struktur der gesamten
Systems innerhalb der Entwicklungsdisziplinen Spezifikationsdokumente. Ihre festegelegten Voll-
(Software, Elektrik/Elektronik und Mechanik) ständigkeitsstufen bilden die messbare Grundlage
festgelegt. Folgende Artefakte bestimmen die für Reviews und Entscheidungen in Produktdefini-
System-Specification Artefaktgruppe: tion und Realisierung. Für ihre einfache Darstellung
sind diese Vollständigkeitsstufen durch Prozent-
· User–Interface-Specification und User-Documentation be- zahlen der RE-Artefakte zusammengefasst. Sie
schreiben die Nutzungsschnittstelle und mögliche Abläufe repräsentieren den gewünschten Grad an Qualität
wie die Nutzer das System benutzen können. und Vollständigkeit zu dem erreichten Zeitpunkt des
· Functional-System-Concept: Detaillierte Systeman- betreffenden Entscheidungspunktes. Zugehörige
forderungen spezifizieren die erforderlichen Versionen der Spezifikationsdokumente bilden die
Systemdienste/Funktionen, mit entsprechenden Anfor- Decision-Base (Entscheidungsbasis) D(i) für Meilen-
derungen an Interaktion, Verhalten, Datenstrukturen, steine oder Quality Gates im Entwicklungsprozess,
das zugrunde liegende Datenmodell und die Nut- und sie sind Input für die artefakt-spezifische
zungsbedingungen des Systems. Gemeinsam mit der Planung (Plan) und Durchführung iterativer
External-Interface-Specification wird die Integration des Konstruktions- (Develop) und Abstimmungsaktivi-
Systems in das Gesamtsystem definiert. täten (Verify) der interdisziplinären Anforderungs-
· External-Interface-Specifications definieren die Schnittstellen und Systemdefinition.
des Systems zu kooperierenden Komponenten und Sys- REM geht von einer grundlegenden iterativen
temen der Umgebung und zu genutzten Software- und Erarbeitung der Systemspezifikation aus, in der An-
Hardware-Komponenten. forderungen und Lösungskonzepte in wechselnden
· Design-Constraints begrenzen den detaillierten Sys- Phasen der Entwicklung und Abstimmung (Develop
tementwurf und die Realisierung innerhalb der und Verify) systematisch mithilfe grundlegender
Engineering-Disziplinen. methoden-abhängiger Modellierungskonzepte
· System-Test-Criteria bilden Akzeptanz- und Testkriterien für analysiert (Analyze), verfeinert (Refine), struktu-
Systemintegration und Evaluierung. riert/modelliert (Structure & Model), vervollständigt
und konsolidiert (Complete) werden.
Diese drei Gruppen des RE-Artefaktmodells zielen Anzahl und inhaltliche Gestaltung solcher
auf die vorherrschenden Inhalte der wesentlichen vordefinierten Entscheidungspunkte sind abhängig
13. Abb. 8 Prozessdefinition mittels Vollständigkeitsstufen von Spezifikationsdokumenten
vom der jeweils gewählten Prozessstrategie, z.B. · Prozessstrategie – Entscheiden über die Prozessstrategie
einer agilen, komponenten-orientierten oder eher und Festlegen der Reihenfolge in der die RE-Artefakte zu
traditionellen Vorgehensweise. erarbeiten und zu vervollständigen sind und entsprechende
Definition der Entscheidungspunkte, Meilensteine oder
Tailoring Quality-Gates. REM empfiehlt ein iteratives und review-
Die artefakt-orientierte Prozessdefinition erfolgt basiertes Vorgehen.
nach folgenden Tailoringschritten: · Zuordnen von Teammitgliedern zu Rollen und von Rollen
zu Spezifikationsdokumenten und Inhalten (RE-Artefakte).
· Pruning des Artefaktmodells – Zuschneiden und Anpassen In Anlehnung an das Microsoft Teammodell [24] definiert
der zu erarbeitenden Anforderungsinhalte (RE-Artefakte) das Rollenkonzept in REM grundlegende Rollen-Cluster
und Spezifikationsdokumente. REM definiert mandatory, und ihre Zuständigkeit für Teile des Artefaktmodells. Für
recommended, optional RE-Artefakte und Inhaltspunkte jedes RE-Artefakt sind in REM Responsible- und Contributing-
(Content-Items). Rollen definiert.
· Auswählen, Zuordnen und Anpassen von Methoden und
Beschreibungstechniken für das Herausarbeiten und Abbildung 9 fasst das Tailoring-Konzept von REM
Spezifizieren der RE-Artefakte und Content-Items. zusammen: Aktivitäten (Activities), Meilensteine
Abb. 9 Überblick über artefakt-orientiertes
Prozess-Tailoring in REM
14. { REQUIREMENTS-ENGINEERING
Abb. 10 Meilensteindefinition in REM am Beispiel des Siemens Product-Life-Cycle-Process (PLM)
(Decision-Gates) und Rollen (Roles) sind nach die zielorientierte und effektive Entwicklung von
RE-Artefakten (RE-Artifacts) bzw. Spezifikations- Anforderungen und Systemkonzepten.
dokumenten (Documents) strukturiert. Durch das Abbildung 10 zeigt ein Beispiel des Tailoring
Tailoring erfolgt die domänen-/projektspezifische in REM anhand des Siemens Product-Life-
Anpassung des Artefaktmodells, die Festlegung Cycle-Process (PLM) und der entsprechenden
der Spezifikationsdokumente und die Definition Vollständigkeitsstufen der Spezifikationsdokumente
der Entscheidungspunkte mittels dokumentspezifi- an den PLM-Meilensteinen M100, M150, und M200.
scher Art und Vollständigkeitsstufen. Dies schließt
die Festlegung von Methoden und Tools für die Methoden und Werkzeugunterstützung
Konstruktion der Artefakte und Dokumente mit ein. für REM
Das Ergebnis der Prozessinstanziierung ist Der Ansatz REM liefert ein Referenzmodell für
ein Arbeitsplan mit Aktivitäten zur Erarbeitung die Struktur und Inhalte der Ergebnisse des
der Dokumente, RE-Artefakte und ihrer Inhalte. Requirements-Engineerings. REM ist in seiner
Entsprechend der definierten Vollständigkeitsstufen jetzigen Form weitgehend methoden-, werkzeug-
können die zugehörigen Dokumente iterativ in und prozessunspezifisch. In zukünftigen Schritten
Versionen entwickelt werden. werden Methoden in REM integriert. In [16] wer-
Durch die Bereitstellung von Templates, den explizit für alle Artefakte die heute üblichen
Checklisten, Methoden und Tools bietet das Methoden zur Beschreibung aufgezählt. Eine spe-
artefakt-basierte Tailoring in REM die Grund- zielle Betonung oder Bewertung objektorientierter
lage für Qualitäts- und Fortschrittsmessung im Methoden wird nicht durchgeführt. Generell sind
Requirements-Engineering und damit die Basis für Strukturierungs- und Modularisierungskonzepte
15. für alle Methoden insbesondere in Hinblick auf erreichen, ist es unabdingbar, Erfahrungen aus in-
eine zufrieden stellende Skalierbarkeit essenziell. dustriellen Softwareprojekten zusammenzuführen.
Daher sind entsprechende Methoden für industrielle Wesentlich zu klären ist die Frage, welche einzel-
Projekte vorzuziehen. nen Methoden für die Erarbeitung der Artefakte
Eine besondere Rolle kommt dem Prototyping sich anbieten und wie diese Methoden ineinander
im Requirements-Engineering zu. Prototyping kann greifen. Für den praktischen Einsatz von REM sind
insbesondere bei vagen Anforderungen und hoch Instanzen zu bilden, die auch die Wahl spezieller
innovativen Produktentwicklungen in den Entwick- Methoden für die Erarbeitung der Artefakte und ent-
lungsprozess systematisch integriert werden, um die sprechender Unterstützungswerkzeuge umfassen.
Stakeholder in die Anforderungsanalyse intensiver Diese Instanzen bilden dann umfassendere konkrete,
einzubinden. Prototyping kann zur Erarbeitung der praktisch einsetzbare Vorgehensmodelle für das
Artefakte in das Referenzmodell integriert werden, Requirements-Engineering. Die Bildung spezifischer
ist aber letztlich nur eine Methode zur Erfassung Instanzen ist aktuelles Thema laufender Forschungs-
und Konsolidierung von Anforderungen und daher arbeiten an der Technischen Universität München
nicht im Fokus dieser Arbeit. und bei Siemens Corporate Research Princeton.
Zur Werkzeugunterstützung von REM gibt es Verschiedene Formen der Anwendung bieten
einen ersten Prototyp, der parallel zur Entwicklung sich für REM an. REM kann als Methoden-
von REM entstanden ist. Es handelt sich dabei Framework, als Planungswerkzeug für anstehende
um das von der TUM entwickelte Requirements- Requirements-Engineering-Projekte, als Bewer-
Management und Systemspezifikationswerkzeug tungswerkzeug für laufende oder abgeschlossene
AutoRAID/AutoFocus [17, 36]. Das Werkzeug betont Requirements-Engineering-Projekte, als Bei-
den Ansatz des modellbasierten Requirements- spielsammlung (Best Practice) für (ausgewählte)
Engineering. Es ist prototypisch umgesetzt und Requirements-Engineering-Projekttypen etc. ein-
anhand von Fallstudien erfolgreich erprobt. gesetzt werden. Damit können dann auch bekannte
Schwächen im Requirements-Engineering von Soft-
Fazit und Ausblick wareprojekten (z. B. Dokumentation, Skalierbarkeit,
Es bleibt die Frage, was wir bisher mit REM er- Implementierbarkeit, Änderungsmanagement, und
reicht haben. Das entwickelte Referenzmodell Metriken zur Bewertung der Qualität der Anforde-
für Requirements-Engineering (REM) ist ein rungen und der Anforderungsprozesse) aufgedeckt
erster wichtiger Schritt um sich das Thema des und behoben oder sogar frühzeitig vermieden
Requirements-Engineering durch Systematisierung werden.
stärker zu erschließen. Es dient zum Abstecken
der Bestandteile eines umfassenden Requirements- Literatur
Engineering-Ansatzes und wird dazu beitragen, dass 1. Achatz, R., Berenbach, B., Broy, M., Kazmeier, J., Ros, J., Rudorfer, A., Subrama-
ein einheitlicheres und strukturiertes Verständnis nyan, R.: Requirements Engineering: A Key to Business Success for Siemens.
Siemens Corporate Research (SCR) Technical Report, March (2006)
für das Thema Requirements-Engineering erreicht 2. AutoFocus: AutoFocus – A CASE tool for Requirements, Design, Code Generation
wird – und zwar für Forschung und die industri- and Simulation: http://www4../∼af2 (2006)
3. Berenbach, B.: Requirements Engineering Checklist. Siemens Corporate Research
elle Praxis. Die flexible Prozessdefinition und das (SCR) SE, Internal Publication (2005)
Tailoring erlauben es zudem, einen Requirements- 4. Boehm, B., Pappaccio, C.: Understanding and Controlling Chaos. IEEE Transactions
of Software Engineering, October (1988)
Engineering Prozess projektspezifisch anzupassen. 5. Braun, P., Lötzbeyer, H., Schätz, B., Slotosch, O.: Consistent Integration of Formal
Damit werden sowohl das Vorgehen als auch die Methods. In: Proc. Intl. Conf. On Tools fort he Analysis of Correct Systems
(TACAS), LNCS 2280 (2006)
Kommunikation zwischen Projektbeteiligten (z.B. 6. Broy, M., Deissenboeck, F., Pizka, M.: Demystifying Maintainability. WoSQ ’06:
Produktmanagement, Forschung & Entwicklung, Proceedings of the 4th Workshop on Software Quality (2006)
Marketing und Verkauf) abgestimmt. 7. Broy, M., Stoelen, K.: Specification and Development of Interactive Systems.
Springer (2001)
Viele Fragen sind auch durch REM in seiner 8. Carroll, J.: Scenario-Based Design: Envisioning Work and Technology in System
aktuellen Form naturgemäß nicht beantwortet und Development. Wiley & Sons (1995)
9. Chaos Report 2001: http://www.projectsmart.co.uk/docs/chaos_report.pdf
viele Forschungsthemen sind noch nicht bearbeitet. 10. Cohen, D., Larson, G., Ware, B.: Improving Software Investment Through Require-
Um REM als Referenzmodell zu etablieren, ist es ments Validation. Sente Corporation (2002)
11. Deissenboeck, F., Seifert, T.: Kontinuierliche Qualitätsüberwachung mit ConQAT.
notwendig, das Modell für die Forschung und Praxis Jahrestagung der Gesellschaft für Informatik 2006, Workshop Software-Leitstände
weiter auszuarbeiten und zu verfeinern. Um dies zu (2006)
16. { REQUIREMENTS-ENGINEERING
12. Doerr, J., Kerkow, D., Koenig, T., Olsson, T., Suzuki, T.: Non-Functional Require- 23. McConnell, S.: Rapid Development: Taming Wild Software Schedules. Microsoft
ments in Industry – Three Case Studies Adopting the ASPIRE NFR Method. IESE- Press (1996)
Report No. 025.05/E (2005) 24. Microsoft Solution Framework (MSF) Team Model. White Paper. 2002. Homepage:
13. Ebert, C.: Requirements Before Requirements: Understanding the Upstream Im- http://www.microsoft.com/msf (2006)
pacts. In: Proceedings RE’05, Paris (2005) 25. Nesland, S.: Initial Lessons Learned from the Definition and Implementation of
14. Firesmith, D.: A Business Case for Requirements Engineering. Presentation at SEI, a Platform Requirements Engineering Process at Intel Corporation. In: Proceedings
September 2003: http://www.sei.cmu.edu/programs/acquisition-support/ RE’05, Paris (2005)
presentations/firesmith/business-case/case.pdf (2006) 26. Paech, B., Von Knethen, A., Doerr, J., Bayer, J., Kerkow, D., Kolb, R., Trendowicz,
15. Geisberger, E.: Requirements Engineering Eingebetteter Systeme – ein interdiszi- A., Punter, T., Dutoit, A.: An Experience-Based Approach for Integrating Architec-
plinärer Modellierungsansatz. Dissertation, Technische Universität München, 2005. ture and Requirements Engineering, ICSE’03 Workshop “From Software Require-
Shaker Verlag, ISBN: 3-8322-4619-3, www.shaker-online.com/ ments to Architectures” (2003)
16. Geisberger, E., Berenbach, B., Broy, B., Kazmeier, J., Paulish, D., Rudorfer, A.: Re- 27. Pohl, K., Brandenburg, M., Gülich, A.: Integrating Requirement and Achitecture
quirements Engineering Reference Model (REM). Technischer Bericht TUM-I0618, Information – A Scenario and Meta-Model Based Approach. In: Proc. of REFSQ
TU München, November (2006) 2001 Workshop. Interlaken, Schweiz (2001)
17. Geisberger, E., Schätz, B.: Modellbasierte Anforderungsanalyse mit AutoRAID. 28. Pohl, K., Haumer, P.: Modelling Contextual Information about Scenarios. In: Proc.
GI Informatik – Forschung und Entwicklung, Springer Verlag (2007) of the 3rd Intl. Workshop on Requirements Engineering – Foundation of Software
18. Halmans, G., Kamsties, E., Pohl, K., Reis, S., Reuys, A.: Seamless Transition from Quality (REFSQ ‘97). University Press Namur, Barcelona, Spain (1997)
Requirements to Test Cases: How to Test a Software Product Line? In: Proceed- 29. QUASAR-Projekt. Homepage: http://www.first.fraunhofer.de/quasar (2006)
ings of the Conference on Software Testing, ICSTEST-E (Bilbao, Spain, November 30. Standish Group Reports: http://www.standishgroup.com/sample_research/
2004). SQS, Düsseldorf (2004) PDFpages/q3-spotlight.pdf (2006), http://www.standishgroup.com/
19. Jones, C.: Applied Software Measurement – Assuring Productivity & Quality. New sample_research/Pdfpages/extreme_chaos.pdf (2006)
York, McGraw Hill (1996) 31. Sommerville, I.: Software Engineering. 7th Edition. Addison Wesley (2004)
20. Jones, C.: Estimating Software Requirements. In CROSSTALK – The Journal of De- 32. TROPOS-Projekt. Homepage: www.troposproject.org/ (2006)
fense Software Engineering, June 2002: http://www.stsc.hill.af.mil/crosstalk/ 33. Wiegers, K.: Software Requirements. 2nd Edition, Microsoft Press (2003)
2002/06/jones.pdf (2006) 34. Wiegers, K., Lawrence, B., Ebert, C.: The Top Risks of Requirements Engineering.
21. Kazman, R., Klein, M., Clements, P.: ATAM: Method for Archtecture Evaluation. IEEE Software, November/December (2001)
Technical Report, CMU/SEI-2000-TR-004 (2000) 35. V-Modell XT. http://www.v-modell-xt.de/ (2006)
22. Lamsweerde, A., Darimont, R., Letier, E.: Managing Conflicts in Goal-Driven Re- 36. Wild, D.: AutoFocus 2 – Das Bilderbuch. Technische Universität München, Techni-
quirements Engineering. IEEE Trans. Software Eng. 24(11), 908–926 (1998) cal Report: TUM-I0610, May (2006)