Aus Software werden heutzutage gewaltige Architekturengebaut, die höchste Anforderungen an Qualitätsattributewie Usability, Performance, Änderbarkeit, Übertragbar-

keit und Interoperabilität erfüllen sollenˇ[a]. Entsprechende Auf-merksamkeit genießt das Requirements Engineering solcherSysteme. Die Anforderungslage eingebetteter Systeme erscheintauf den ersten Blick vergleichsweise trivial: Ein Backofen sollheizen, ein Tempomat soll die Geschwindigkeit halten, eine In-fusionspumpe soll eine Spritze leer drücken. Die Bedienober-fläche ist oftmals schlicht oder nicht vorhanden, die Interaktionmit anderen Systemen gering.

Herausforderung Embedded

Zeitgemäßes Requirements Engineering für Software stellt denBenutzer in den Mittelpunkt, und das ist auch gut so. Beim ein-gebetteten System kommt die physikalische Umgebung als In-teraktionspartner hinzu. Mit ihm steht das eingebettete Systemüber Sensoren und Aktoren in Kontakt.

Der Benutzer wirkt mit Eingaben, die Umgebung hingegenüber Sensoren auf das System. Dieses wiederum beeinflusstseine Umgebung mit den Aktoren und macht Ausgaben auf derBenutzerschnittstelle. Dazu kommt vermehrt die Kommunika-tion mit anderen Systemen. Es bietet sich an, die Anforderun-gen entsprechend zu partitionieren, beispielsweise: Wie inter -agiert das System mit dem Benutzer? Wie wirken Sensoren aufdas System? Wie reagiert das System mittels seiner Aktoren?Wie interagiert es mit anderen Systemen? Die benutzerzentrier-

te Sicht bleibt also bestehen, ist aber durch weitere Sichten zuergänzen.

Auch das Fortschreiten der realen Zeit hat eine größere Be-deutung. Gewisse Reaktionen des Systems müssen zuverlässigund exakt zu bestimmten Zeitpunkten erfolgen. Man spricht vonharten Echtzeitanforderungen. Bei vielen Anwendungen genügtim Allgemeinen, den Zeitanforderungen meistens oder im Durch-schnitt zu entsprechen. Es handelt sich um weiche Echtzeitan-forderungen. Das Vorhandensein harter Echtzeitanforderungenhat massiven Einfluss auf die Systemarchitektur und ist dahermit großer Sorgfalt zu prüfen.

Komplexer als vermutet

Die Dokumentation der Anforderungen an „reine“ Softwarekommt oftmals mit wenigen Beschreibungstechniken wie Be-nutzungsabläufen und informellen textuellen Beschreibungenaus. Die effiziente Dokumentation der Anforderungen an eineeingebettete Software ist hingegen nur mit dem kompletten Satzder UML (Unified Modeling Languageˇ[b]), Verhaltensdiagram-men oder einem ähnlich umfangreichen Werkzeugkasten mög-lich. Diagramme und andere halbformale und formale Beschrei-bungstechniken stellen für den, der mit der Syntax nicht vertrautist, eine Verständnishürde dar. Ab einer gewissen Komplexitätder Anforderung lohnt sich jedoch, diese Hürde zu überwinden,weil andere Darstellungsformen noch schlechter verständlichwären. Einheitlich muss es nicht sein. Unterschiedliche Anfor-derungen haben unterschiedliche Kreise von Lesern. Die einen

!" iX Developer "/"#$% – Embedded Software

QUALITÄTSSICHERUNG | ANFORDERUNGEN

Requirements Engineering für eingebettete Systeme

AbgeklopftMatthias Kraaz

Eingebettete Systeme verlangen spezielles Know-how vom Requirements Engineer, insbesondere wenn die Themen Safety und regulierte Entwicklung hinzukommen. Ein Survival Guide, um an den wichtigsten Klippen vorbeizusteuern.

xx.1414.062-065 03.02.14 09:30 Seite 62

© Copyright by Heise Zeitschriften Verlag

Anforderungen sind nur technisch relevant, die anderen essen-ziell für das Marketing. Jede Anforderung sollte dem Problemund den Adressaten angemessen beschrieben werden.

Bei der Definition von Benutzungsabläufen ist zu beachten,dass der Interaktionspartner Umgebung nicht ausgesperrt wer-den kann. Physikalische Prozesse und die Zeit laufen weiter, vonSensoren gemeldete Ereignisse treten auf – völlig unabhängigvon den Benutzereingaben. Das System muss reagieren, auchwenn der Benutzer gerade etwas anderes vorhatte. Jede Defini-tion eines Benutzungsablaufs muss also Unterbrechungen undVerzweigungen durch solche Ereignisse berücksichtigen. Umdie Komplexität dieses Zusammenspiels in den Griff zu bekom-men, empfiehlt sich die klare, eindeutige Definition von Sys-temzuständen, auf denen Benutzer und Ereignisse gemeinsamoperieren. Die Beschreibungstechnik der Wahl sind Zustands-maschinen.

Der Interaktionspartner Umgebung meint es übrigens nichtimmer gut mit dem System. Mechanische Belastung (zum Bei-spiel Vibration und Schlag) und elektromagnetische Immissio-nen beeinflussen über den Umweg der Sensoren die Software.Daher ist die Resistenz gegen solche Einflüsse nicht nur als An-forderung an die Hardware, sondern auch als nichtfunktionaleAnforderung an die Software zu betrachten.

Nicht nur die besonderen Aufgaben eines eingebetteten Sys-tems, auch sein Aufbau aus Hardware und Software sorgt fürKomplexität beim Requirements Engineering. Die Produktionfertigt die Hardware aus den zugelieferten Bauteilen, spielt dieSoftware auf und testet die fertigen Geräte. Entsprechende An-forderungen meldet dieser zusätzliche Stakeholder an: Er mussdie Fertigung mit den ihm zur Verfügung stehenden Mittelnmöglichst effizient durchführen können. Daraus generieren sichvor allem Anforderungen an Testfunktionen, die die Softwarebereitstellen muss, und den Ablauf zur Installation der Softwareauf dem Gerät. Nach der Inbetriebnahme übernimmt der Servicedie Wartung der Geräte. Die Stakeholder „Produktion“ und„Service“ werden leider regelmäßig verspätet berücksichtigt.

Beziehungsgeflecht

Die Kosten für die Bauteile der Hardware und die Kosten derProduktion ergeben zusammen die Herstellkosten eines Sys-tems. Manche Systeme werden nur einmalig oder in geringerZahl gebaut, andere Geräte millionenfach hergestellt. Je nachStückzahl verdrängen die Herstellkosten pro Gerät die Kosten fürdie Entwicklung des Geräts in der Bedeutung für das Require-ments Engineering. Bei portablen Geräten geht auf ähnlicheWeise der Stromverbrauch ein. Soll das neue Gerät eine attrak-tive Oberfläche erhalten, ist dann nicht gefragt, wie viele Ent-wicklerstunden das kostet, sondern wie teuer ein Prozessor mitausreichender Leistung ist und wie viel Strom er verbraucht. DerFaktor Entwicklungsdauer ist dafür gleichermaßen relevant:Günstige Zeitfenster und Termine gibt es für eingebettete Sys-teme wie für gewöhnliche Software.

Die Entwickler des Systems melden auch Ansprüche an. Bei-spielsweise soll das Gerät bei einem Fehler in der Software denEntwicklern möglichst viele Informationen für die Fehlerbehe-bung zur Verfügung stellen. Solche Anforderungen haben auchdie Hardwareentwickler während der Tests auf elektromagneti-sche Verträglichkeit (EMV-Tests): Sie brauchen anschließendInformationen über Probleme im System aufgrund bestimmterEinstrahlungen. Der Stakeholder „Entwicklung“ existiert genau-so bei reiner Software, nur sind dort die Anforderungen leichterzu befriedigen als bei einem verschlossenen, blinkenden Kasten.

Eine frühzeitige Berücksichtigung des Stakeholders ist somitweniger wichtig.

Für die Verfeinerung der Anforderungen an ein eingebettetesSystem werden oftmals Spezialisten für Software, Elektronik,Mechanik und eventuell weiteren beteiligten Disziplinen benö-tigt. Die Auftrennung in eine Software- und eine Elektronik-An-forderungsdefinition ist zwar üblich, suggeriert aber eine Unab-hängigkeit, die nicht vorhanden ist. Die Spezialisten müssen engzusammenarbeiten, damit Systemanforderungen nicht zwischenden Disziplinen herunterfallen und sich letztlich viele Systeman-forderungen nur durch mehrere Disziplinen gemeinsam erfüllenlassen.

Requirements Engineering für eingebettete Systeme ist abernicht nur komplexer, sondern auch handfester. Ein eingebettetesSystem interagiert direkt mit physikalischen Entitäten. Es istsinnvoll, diese tatsächlich mal in die Hand zu nehmen oder sichihre Verwendung demonstrieren zu lassen. Viele Fragen undFehler in der Anforderungsdefinition lassen sich so umgehen.

Herausforderung regulierte Entwicklung

Medizinprodukte, Automobile, Schienenfahrzeuge und andereProdukte unterliegen gesetzlichen Auflagen. Die Erlaubnis zuihrem Vertrieb beziehungsweise Einsatz ist an die Einhaltunggewisser Normen bei Entwicklung und Herstellung geknüpft.Man spricht von regulierter Entwicklung oder Entwicklung imregulierten Umfeld.

Die zu erfüllenden Normen lassen sich nach Prozess- undProduktnormen unterscheiden. Erstere formulieren Anforderun-gen an das Vorgehen bei der Entwicklung, Produktnormen hin-gegen Anforderungen an die Beschaffenheit und das Verhaltendes fertigen Geräts. Mit der Einhaltung der Anforderungen istes jedoch nicht getan, für die Zulassung des Produkts sindschriftliche Beweise für deren Einhaltung zu liefern. Als Nach-weis, dass die Prozessnormen eingehalten wurden, dient die de-taillierte Dokumentation des Vorgehens während der Entwick-lung. Das Gerät, die Dokumentation seiner Beschaffenheit unddas Bestehen geforderter Tests sind Nachweise, dass man sichan die Produktnormen gehalten hat.

Je nach Kritikalität des Produkts und Branche wird mehr oderweniger gefordert. Beispielsweise verlangt die Zulassung aucheinfacher Medizinprodukte viele Meter Papier, wobei ein Groß-teil den Prozessnormen geschuldet ist, während für Brandmel-deanlagen hauptsächlich eine produktbezogene Dokumentationabzugeben ist. Das steht dem Credo des modernen Require-ments Engineering entgegen, das lautet: mehr kommunizieren,weniger dokumentieren. Ein Mehr an Kommunikation ist sicher-

iX Developer "/"#$% – Embedded Software !&

Entwicklung

Produktion

Service

Anwender

Normen

Risiko-management

HerstellkostenRE

Das eingebettete System reagiert nicht nur auf den Benutzer(Abb.ˇ1).

xx.1414.062-065 03.02.14 09:30 Seite 63

© Copyright by Heise Zeitschriften Verlag

lich begrüßenswert, eine Reduktion der Dokumentation kannaber zu Problemen bei der Zulassung führen.

Regulatives Qualitätsmanagement

Üblicherweise stellt ein Qualitätsmanagementsystem (QMS) dieEinhaltung der Prozessnormen sicher. Es setzt die Anforderun-gen der Prozessnormen in eine Fülle von Prozessdefinitionen,Listen zu erstellender Dokumente, Arbeitsvorschriften und Do-kumentenvorlagen um. Mit der einmaligen Erstellung des QMSist es aber nicht getan. Der Hersteller regulierter Erzeugnissemuss Vorkommnisse bei eigenen Produkten und ähnlichen Wa-ren anderer Hersteller überwachen und gegebenenfalls das QMSergänzen und verbessern, damit sich ähnliche Vorkommnissenicht wiederholen. Regelmäßig wird das QMS von Zulassungs-behörden wie der amerikanischen FDA auditiert. Stellen dieFDA-Inspektoren Mängel im QMS fest, erhält das Unternehmeneinen sogenannten Warning Letter. Unangenehm ist daran, dassdiese Briefe öffentlich einsehbar sind. Der Qualitätsmanage-mentbeauftragte (QMB) wacht über die laufende Verbesserungund die Einhaltung des QMS und steht bei Fragen zum QMSberatend zur Seite. QMS und QMB ersparen den Entwicklernvon Embedded-Systemen also die Beschäftigung mit den Pro-zessnormen, verlangen dafür aber – auch motiviert durch dieAngst vor einem Warning Letter oder ähnlichen Rügen – einestrikte Einhaltung der Vorgaben des QMS.

Das QMS und die Prozessnormen sind keine inhaltlichenTreiber des Requirements Engineering, etablieren aber einzu-haltende Randbedingungen. Vom QMS erfasste Dokumentemüssen gewissen Prinzipien gehorchen. Vor seiner weiteren Ver-wendung haben die dazu bestimmten Personen das Dokumentzu prüfen und mit ihren Unterschriften freizugeben. Die Unter-schriftenliste des zu erstellenden Anforderungsdokuments ist ei-ne wichtige Informationsquelle. Sie identifiziert eine minimalzu berücksichtigende Gruppe von Stakeholdern, deren Bedürf-nisse hinsichtlich Form und Inhalt des Anforderungsdokumentszu befriedigen sind. Wählen Systemingenieure dabei Notations-formen, die für diese Gruppe nicht verständlich sind, verhindertdas eventuell die Freigabe. Die Vorgabe der Unterschriftenlistesollte allerdings nicht davon abhalten, auf die Suche nach wei-teren Stakeholdern zu gehen. Bei der Wahl der Sprache, in derdas Dokument abgefasst wird, sind auch die Zulassungsbehör-den zu berücksichtigen. Wer eine internationale Zulassung an-strebt, ist mit Englisch auf der sicheren Seite. Die Unterschrif-tenliste eines Anforderungsdokuments kann recht lang sein.Dadurch wird jede nachträgliche Änderung zum Kraftakt.

Bevor man das Anforderungsdokument zur Freigabe vorlegt,empfiehlt es sich, Vorabversionen zu zirkulieren und Feedback

einzusammeln. Diese müssen klar als solche gekennzeichnetwerden. Zur Freigabe wird diese Markierung entfernt und durchdie endgültige Versionsnummer ersetzt. Die Art der Markierungund die Nummerierung von Versionen entsprechen wiederumden Vorgaben des QMS. In der Änderungshistorie des Doku-ments werden sämtliche Versionen mit den jeweiligen Änderun-gen am Dokument aufgeführt.

Für wichtige Dokumente wie die Anforderungsdefinitionhält das QMS Dokumentenvorlagen bereit. Die in diesen ent-haltene Struktur darf für gewöhnlich weiter unterteilt werden.Jede andere Änderung der Struktur sollte unterlassen, das Leer-bleiben von Kapiteln kurz begründet werden. Beim Inhalt hin-gegen herrscht die Freiheit, beliebige moderne Ansätze wie„Specification by Example“ˇ[1] und – im Rahmen der Verständ-lichkeit für die Stakeholder – beliebige Beschreibungstechnikenzu verwenden.

Die Prozessnormen verlangen eine Rückverfolgbarkeit derAnforderungen auf die Umsetzung sowie den Test und umge-kehrt. Zu jeder Anforderung ist anzugeben, wo die Umsetzungund der Test der Umsetzung beschrieben ist. Bei einer schritt-weisen Ableitung der Umsetzung aus den Anforderungen überverfeinerte Anforderungen muss auch eine Rückverfolgbarkeitvon der ursprünglichen Anforderung auf die Verfeinerung si-chergestellt sein. Das gilt auch für den umgekehrten Weg: JederTest, jedes Detail der Umsetzung muss auf eine Anforderung zu-rückführbar sein.

Die Mehrheit der QMS im regulierten Umfeld definiert einsequenzielles Vorgehen. Das mag archaisch anmuten, herrschendoch mittlerweile iterativ-inkrementelle Vorgehensmodelle inder IT-Industrie vor. Die Ursache liegt zum einen darin, dass einsequenzielles Vorgehen die nächstliegende Umsetzung der An-forderungen der Prozessnormen darstellt. Zum anderen wird eineinmal etabliertes QMS ungern überarbeitet, hat es sich dochbei der erfolgreichen Zulassung von Produkten und der Vermei-dung oder Beschwichtigung von Rügen der Auditoren vielfachbewährt. Auch wenn eine projektspezifische Anpassung des Vor-gehens vom QMS vorgesehen ist, unterbleibt diese doch meistaus Scheu vor dem Aufwand und aus Angst, die Zulassung zuverpatzen. Innerhalb der sequenziell zu absolvierenden Projekt-phasen ist aber ein iterativ-inkrementelles Vorgehen möglichund sinnvoll: „Unter der Haube“ des sequenziellen Vorgehenswerden die zu produzierenden Dokumente iterativ-inkrementellerstellt.

Herausforderung sicherheitsbezogenes SystemWährend das QMS die Prozessnormen haarklein in Arbeitsan-weisungen übersetzt, bleibt dem Entwicklungsteam die einge-hende Beschäftigung mit den Produktnormen in der Projektar-beit nicht erspart. Die Anforderungen der Produktnormen könnensich deutlich im für den Anwender sichtbaren Verhalten des Sys-tems niederschlagen. Beispielsweise sind die Tonfolgen derAlarmsignale von Infusionspumpen in einer Produktnorm präzisedefiniert. Die Mehrheit der Anforderungen bezieht sich aber auftechnische Details der Umsetzung, beispielsweise die Wider-standsfähigkeit gegen elektromagnetische Immissionen, Über-spannung, Stürze oder Maßnahmen zum Schutz von Menschund Umwelt.

Primäres Ziel der Regulierung und der einzuhaltenden Nor-men und Vorschriften ist die Gewährleistung der Sicherheit vonMensch und Umwelt. Gegenstand der Regulierung sind sicher-heitsbezogene Systeme, deren Ausfall oder Störung Mensch und

!% iX Developer "/"#$% – Embedded Software

QUALITÄTSSICHERUNG | ANFORDERUNGEN

Benutzer Schnittstellen

eingebettetesSystem

EchtzeitSensoren

Faktoren, die das Requirements Engineering beeinflussen(Abb.ˇ2)

xx.1414.062-065 03.02.14 09:30 Seite 64

© Copyright by Heise Zeitschriften Verlag

Umwelt gefährden kann. Dieser Sicherheitsbezug wirkt sich ver-schiedentlich auf das Requirements Engineering aus.

Kein System ist fehlerlos oder gefeit gegen Ausfall oderFehlbedienung. Risikomindernde Maßnahmen begrenzen Risi-ken auf einem akzeptablen Niveau. Solche Maßnahmen forderneine bestimmte Art der Konstruktion oder des Verhaltens desSystems. Risikomindernde Maßnahmen sind also zusätzliche,kaum verhandelbare Anforderungen. Im Extremfall ist die Ent-wicklung eines Systems abzubrechen, wenn die Begrenzung derRisiken aus wirtschaftlichen oder technischen Gründen nichtmöglich ist.

Die Identifizierung und Bewertung von Risiken liegt in derVerantwortung eines Risk Manager, der sich mit dem Umfelddes Systems gut auskennt. Bei der Identifizierung wird er vonallen an der Entwicklung Beteiligten unterstützt. Der Entwurftechnischer Lösungen zur Risikominderung ist die Aufgabe ei-nes technisch orientierten Safety Engineer. Beide Rollen könnenje nach Branche eine einzelne oder mehrere Personen erfüllen,erfordern aber aufgrund der nötigen Methodenkenntnisse Spe-zialisten. Diese Spezialisten übernehmen auch die Interpretationder Produktnormen.

Mit Blick auf Risiken werden Sicherheitsabfragen gefordertoder ein intelligentes, autonomes Verhalten des Systems verbo-ten. Risikomindernde Maßnahmen gehen also teilweise zu Las-ten der Attraktivität des Produkts. Das Requirements Enginee-ring sollte im Dialog mit dem Risikomanagement Mittel undWege suchen, um die Attraktivitätsnachteile zu minimieren undgleichzeitig die Absicht der Maßnahme zu wahren. Eventuell isteine Abwandlung der Maßnahme möglich, die weniger unange-nehm ist oder besser mit dem allgemeinen Benutzungskonzeptharmonisiert.

Zur Entdeckung von Risiken ist nicht nur der Anwendungs-bereich des Systems, sondern auch das System selbst oder derSystementwurf zu analysieren: Was für Störungen oder Ausfällekönnten an Teilen des Systems auftreten? Welche Wirkung hättedas, was für Gefahren resultieren? Die Formulierung entspre-chender Maßnahmen fällt naturgemäß sehr technisch aus. So-weit möglich, sollte der Requirements Engineer eine einheitlicheSprache in der Anforderungsdokumentation bewahren. Bei al-lem Streben nach Konsistenz darf die ursprüngliche Anforde-rung aus dem Risikomanagement nicht verfälscht werden.

Die Generierung von Maßnahmen aus der Analyse des Sys-tems hat den weiteren unangenehmen Effekt, dass die Grundla-ge dieser Analyse und somit auch resultierende Anforderungeneher spät im Projekt entstehen. Zudem lässt sich das Risikoma-nagement zu keinem Zeitpunkt während der Entwicklung als ab-geschlossen betrachten. Neue Informationen dürfen jederzeit zurDefinition weiterer Maßnahmen führen. Der Umgang mit sol-chen verspäteten Anforderungen ist vorzusehen.

Eine typische risikomindernde Maßnahme ist Diversität. Da-bei wird ein Systemteil redundant ausgelegt und die verschie-denen Instanzen mit unterschiedlichen Mitteln von unterschied-lichen Personen entwickelt. Bei einer zweifachen Diversitätwird also jede Rückfrage wegen Unklarheiten in der Anforde-rungsdokumentation zweimal gestellt werden. Die Zahl derRückfragen wird auch wesentlich höher sein, weil jedes Ent-wicklerteam sichergehen will, die Anforderungen genau gleichverstanden zu haben wie die anderen Teams. Da auch viel Wertauf eine Unabhängigkeit des Testens gelegt wird, kommen dieTester noch mal mit den gleichen Fragen, statt sich mit einemEntwickler über das gewollte Verhalten abzusprechen. Lückenin Anforderungsdefinitionen, die den Entwicklern die Ausgestal-tung überlassen, sind immer noch erlaubt. Die Klarheit über die-se Lücken und ihre Zulässigkeit wird jedoch ungemein wichtig.

Fazit

Eingebettete Systeme – besonders im regulierten Umfeld – habenihre Besonderheiten bezüglich des Requirements Engineering.Vielfach ist aber schlichtweg hervorragendes handwerkliches Ar-beiten, wie es auch in vielen reinen Softwareprojekten wün-schenswert wäre, gefordertˇ[2]. Die Qualitätseigenschaften vonAnforderungen bleiben dieselben: Korrektheit, Machbarkeit,Notwendigkeit, Priorisierung, Eindeutigkeit und Testbarkeit.

Da sich die Entwicklung eingebetteter Systeme eher längerhinzieht, folgt die Strafe für Fehler später dafür umso härter.Entwickler und Tester sollten daher die Anforderungsdokumen-tation frühzeitig einem gründlichen Review unterziehen. Jedehierauf verwendete Minute spart ein Vielfaches an Aufwand imweiteren Projektverlaufˇ[c]. Weitere Methoden zur Validierungvon Anforderungen sind werkzeuggestützte Prüfungen, formaleVerifizierung sowie der Bau von Prototypen und Simulationˇ[d].Statistiken zeigen, dass für die meisten Fehler nachträgliche Än-derungen verantwortlich sindˇ[e]. Daher sollten nachträglicheÄnderungen unbedingt genauso gründlich geprüft werden wiedie initiale Version der Anforderungsdokumentation.

Dem frisch in dieses Umfeld einsteigenden Requirements En-gineer sei also empfohlen, sich auf die allgemeinen Best Practi-ces zu besinnen und die Besonderheiten des neuen Aufgaben-gebietes zu beachten. (ane)

Literatur[1]ˇGojko Adzic; Specification by Example; How Successful

Teams Deliver the Right Software; Manning 2011[2]ˇKarl E. Wiegers; More about Software Requirements; Thorny

Issues and Practical Advice; Microsoft Press 2006

Matthias Kraaz arbeitet bei Zühlke als Lead Software Architect. Seine Spezialgebiete sind Konstruktion und Test sicherheitskritischerund eingebetteter Systeme.

iX Developer "/"#$% – Embedded Software !'

[a] ISO/IEC "'#$#:"#$$, Systems and software engineering – Systems and software Quality Requirements and Evaluation(SQuaRE) – System and software quality modelswww.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=&'(&&

[b] Object Management Group; Unified Modelling Languagewww.uml.org

[c] Karl E. Wiegers; Writing Quality Requirementswww.processimpact.com/articles/qualreqs.html

[d] Manfred Broy; Requirements Engineering for Embedded Systems ($))()www%.in.tum.de/publ/papers/femsys_boesswet_$))(_Conference.pdf

[e] Center for Devices and Radiological Health; General Principles of Software Validation; January $$, "##" (S.ˇ&)www.fda.gov/downloads/RegulatoryInformation/…/ucm$"!)''.pdf?

Onlinequellen

Alle Links: www.ix.de/ix!"!"#$% x

xx.1414.062-065 03.02.14 09:30 Seite 65

© Copyright by Heise Zeitschriften Verlag