QUALITÄTSSICHERUNG | ANFORDERUNGEN 
Requirements Engineering für eingebettete Systeme 
Abgeklopft 
Matthias Kraaz 
Eingebe...
Anforderungen sind nur technisch relevant, die anderen essen-ziell 
für das Marketing. Jede Anforderung sollte dem Problem...
QUALITÄTSSICHERUNG | ANFORDERUNGEN 
lich begrüßenswert, eine Reduktion der Dokumentation kann 
aber zu Problemen bei der Z...
Umwelt gefährden kann. Dieser Sicherheitsbezug wirkt sich ver-schiedentlich 
auf das Requirements Engineering aus. 
Kein S...
Nächste SlideShare
Wird geladen in …5
×

Requirements Engineering für eingebettete Systeme (iX Magazin 2/2014)

508 Aufrufe

Veröffentlicht am

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.
Autor: Matthias Kraaz

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
508
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
4
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Requirements Engineering für eingebettete Systeme (iX Magazin 2/2014)

  1. 1. QUALITÄTSSICHERUNG | ANFORDERUNGEN Requirements Engineering für eingebettete Systeme Abgeklopft Matthias 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. Aus Software werden heutzutage gewaltige Architekturen gebaut, die höchste Anforderungen an Qualitätsattribute wie Usability, Performance, Änderbarkeit, Übertragbar-keit und Interoperabilität erfüllen sollenˇ[a]. Entsprechende Auf-merksamkeit genießt das Requirements Engineering solcher Systeme. Die Anforderungslage eingebetteter Systeme erscheint auf den ersten Blick vergleichsweise trivial: Ein Backofen soll heizen, 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 Interaktion mit anderen Systemen gering. Herausforderung Embedded Zeitgemäßes Requirements Engineering für Software stellt den Benutzer 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 beeinflusst seine Umgebung mit den Aktoren und macht Ausgaben auf der Benutzerschnittstelle. 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 auf das 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 zu ergänzen. Auch das Fortschreiten der realen Zeit hat eine größere Be-deutung. Gewisse Reaktionen des Systems müssen zuverlässig und exakt zu bestimmten Zeitpunkten erfolgen. Man spricht von harten Echtzeitanforderungen. Bei vielen Anwendungen genügt im Allgemeinen, den Zeitanforderungen meistens oder im Durch-schnitt zu entsprechen. Es handelt sich um weiche Echtzeitan-forderungen. Das Vorhandensein harter Echtzeitanforderungen hat massiven Einfluss auf die Systemarchitektur und ist daher mit großer Sorgfalt zu prüfen. Komplexer als vermutet Die Dokumentation der Anforderungen an „reine“ Software kommt oftmals mit wenigen Beschreibungstechniken wie Be-nutzungsabläufen und informellen textuellen Beschreibungen aus. Die effiziente Dokumentation der Anforderungen an eine eingebettete Software ist hingegen nur mit dem kompletten Satz der 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 vertraut ist, eine Verständnishürde dar. Ab einer gewissen Komplexität der Anforderung lohnt sich jedoch, diese Hürde zu überwinden, weil andere Darstellungsformen noch schlechter verständlich wären. Einheitlich muss es nicht sein. Unterschiedliche Anfor-derungen haben unterschiedliche Kreise von Lesern. Die einen !" iX Developer "/"#$% – Embedded Software © Copyright by Heise Zeitschriften Verlag
  2. 2. Anforderungen sind nur technisch relevant, die anderen essen-ziell für das Marketing. Jede Anforderung sollte dem Problem und 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, von Sensoren gemeldete Ereignisse treten auf – völlig unabhängig von den Benutzereingaben. Das System muss reagieren, auch wenn der Benutzer gerade etwas anderes vorhatte. Jede Defini-tion eines Benutzungsablaufs muss also Unterbrechungen und Verzweigungen durch solche Ereignisse berücksichtigen. Um die 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 gemeinsam operieren. Die Beschreibungstechnik der Wahl sind Zustands-maschinen. Der Interaktionspartner Umgebung meint es übrigens nicht immer 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 nichtfunktionale Anforderung an die Software zu betrachten. Nicht nur die besonderen Aufgaben eines eingebetteten Sys-tems, auch sein Aufbau aus Hardware und Software sorgt für Komplexität beim Requirements Engineering. Die Produktion fertigt die Hardware aus den zugelieferten Bauteilen, spielt die Software auf und testet die fertigen Geräte. Entsprechende An-forderungen meldet dieser zusätzliche Stakeholder an: Er muss die Fertigung mit den ihm zur Verfügung stehenden Mitteln möglichst effizient durchführen können. Daraus generieren sich vor allem Anforderungen an Testfunktionen, die die Software bereitstellen muss, und den Ablauf zur Installation der Software auf dem Gerät. Nach der Inbetriebnahme übernimmt der Service die 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 der Produktion ergeben zusammen die Herstellkosten eines Sys-tems. Manche Systeme werden nur einmalig oder in geringer Zahl gebaut, andere Geräte millionenfach hergestellt. Je nach Stückzahl verdrängen die Herstellkosten pro Gerät die Kosten für die Entwicklung des Geräts in der Bedeutung für das Require-ments Engineering. Bei portablen Geräten geht auf ähnliche Weise 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 mit ausreichender Leistung ist und wie viel Strom er verbraucht. Der Faktor 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 den Entwicklern möglichst viele Informationen für die Fehlerbehe-bung zur Verfügung stellen. Solche Anforderungen haben auch die Hardwareentwickler während der Tests auf elektromagneti-sche Verträglichkeit (EMV-Tests): Sie brauchen anschließend Informationen über Probleme im System aufgrund bestimmter Einstrahlungen. Der Stakeholder „Entwicklung“ existiert genau-so bei reiner Software, nur sind dort die Anforderungen leichter zu befriedigen als bei einem verschlossenen, blinkenden Kasten. Eine frühzeitige Berücksichtigung des Stakeholders ist somit weniger wichtig. Für die Verfeinerung der Anforderungen an ein eingebettetes System 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 eng zusammenarbeiten, damit Systemanforderungen nicht zwischen den Disziplinen herunterfallen und sich letztlich viele Systeman-forderungen nur durch mehrere Disziplinen gemeinsam erfüllen lassen. Requirements Engineering für eingebettete Systeme ist aber nicht nur komplexer, sondern auch handfester. Ein eingebettetes System interagiert direkt mit physikalischen Entitäten. Es ist sinnvoll, diese tatsächlich mal in die Hand zu nehmen oder sich ihre Verwendung demonstrieren zu lassen. Viele Fragen und Fehler in der Anforderungsdefinition lassen sich so umgehen. Herausforderung regulierte Entwicklung Medizinprodukte, Automobile, Schienenfahrzeuge und andere Produkte unterliegen gesetzlichen Auflagen. Die Erlaubnis zu ihrem Vertrieb beziehungsweise Einsatz ist an die Einhaltung gewisser Normen bei Entwicklung und Herstellung geknüpft. Man spricht von regulierter Entwicklung oder Entwicklung im regulierten Umfeld. Die zu erfüllenden Normen lassen sich nach Prozess- und Produktnormen unterscheiden. Erstere formulieren Anforderun-gen an das Vorgehen bei der Entwicklung, Produktnormen hin-gegen Anforderungen an die Beschaffenheit und das Verhalten des fertigen Geräts. Mit der Einhaltung der Anforderungen ist es jedoch nicht getan, für die Zulassung des Produkts sind schriftliche 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 und das Bestehen geforderter Tests sind Nachweise, dass man sich an die Produktnormen gehalten hat. Je nach Kritikalität des Produkts und Branche wird mehr oder weniger gefordert. Beispielsweise verlangt die Zulassung auch einfacher Medizinprodukte viele Meter Papier, wobei ein Groß-teil den Prozessnormen geschuldet ist, während für Brandmel-deanlagen hauptsächlich eine produktbezogene Dokumentation abzugeben ist. Das steht dem Credo des modernen Require-ments Engineering entgegen, das lautet: mehr kommunizieren, weniger dokumentieren. Ein Mehr an Kommunikation ist sicher-iX Produktion Entwicklung Service Anwender Normen Risiko-management Herstellkosten RE Das eingebettete System reagiert nicht nur auf den Benutzer (Abb.ˇ1). Developer "/"#$% – Embedded Software !& © Copyright by Heise Zeitschriften Verlag
  3. 3. QUALITÄTSSICHERUNG | ANFORDERUNGEN lich begrüßenswert, eine Reduktion der Dokumentation kann aber zu Problemen bei der Zulassung führen. Regulatives Qualitätsmanagement Üblicherweise stellt ein Qualitätsmanagementsystem (QMS) die Einhaltung 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 QMS ist es aber nicht getan. Der Hersteller regulierter Erzeugnisse muss Vorkommnisse bei eigenen Produkten und ähnlichen Wa-ren anderer Hersteller überwachen und gegebenenfalls das QMS ergänzen und verbessern, damit sich ähnliche Vorkommnisse nicht wiederholen. Regelmäßig wird das QMS von Zulassungs-behörden wie der amerikanischen FDA auditiert. Stellen die FDA-Inspektoren Mängel im QMS fest, erhält das Unternehmen einen sogenannten Warning Letter. Unangenehm ist daran, dass diese Briefe öffentlich einsehbar sind. Der Qualitätsmanage-mentbeauftragte (QMB) wacht über die laufende Verbesserung und die Einhaltung des QMS und steht bei Fragen zum QMS beratend zur Seite. QMS und QMB ersparen den Entwicklern von Embedded-Systemen also die Beschäftigung mit den Pro-zessnormen, verlangen dafür aber – auch motiviert durch die Angst vor einem Warning Letter oder ähnlichen Rügen – eine strikte Einhaltung der Vorgaben des QMS. Das QMS und die Prozessnormen sind keine inhaltlichen Treiber des Requirements Engineering, etablieren aber einzu-haltende Randbedingungen. Vom QMS erfasste Dokumente müssen gewissen Prinzipien gehorchen. Vor seiner weiteren Ver-wendung haben die dazu bestimmten Personen das Dokument zu prüfen und mit ihren Unterschriften freizugeben. Die Unter-schriftenliste des zu erstellenden Anforderungsdokuments ist ei-ne wichtige Informationsquelle. Sie identifiziert eine minimal zu berücksichtigende Gruppe von Stakeholdern, deren Bedürf-nisse hinsichtlich Form und Inhalt des Anforderungsdokuments zu befriedigen sind. Wählen Systemingenieure dabei Notations-formen, die für diese Gruppe nicht verständlich sind, verhindert das eventuell die Freigabe. Die Vorgabe der Unterschriftenliste sollte allerdings nicht davon abhalten, auf die Suche nach wei-teren Stakeholdern zu gehen. Bei der Wahl der Sprache, in der das 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 gekennzeichnet werden. Zur Freigabe wird diese Markierung entfernt und durch die endgültige Versionsnummer ersetzt. Die Art der Markierung und die Nummerierung von Versionen entsprechen wiederum den 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 Anforderungsdefinition hä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 Beschreibungstechniken zu verwenden. Die Prozessnormen verlangen eine Rückverfolgbarkeit der Anforderungen auf die Umsetzung sowie den Test und umge-kehrt. Zu jeder Anforderung ist anzugeben, wo die Umsetzung und der Test der Umsetzung beschrieben ist. Bei einer schritt-weisen Ableitung der Umsetzung aus den Anforderungen über verfeinerte Anforderungen muss auch eine Rückverfolgbarkeit von der ursprünglichen Anforderung auf die Verfeinerung si-chergestellt sein. Das gilt auch für den umgekehrten Weg: Jeder Test, jedes Detail der Umsetzung muss auf eine Anforderung zu-rückführbar sein. Die Mehrheit der QMS im regulierten Umfeld definiert ein sequenzielles Vorgehen. Das mag archaisch anmuten, herrschen doch mittlerweile iterativ-inkrementelle Vorgehensmodelle in der IT-Industrie vor. Die Ursache liegt zum einen darin, dass ein sequenzielles Vorgehen die nächstliegende Umsetzung der An-forderungen der Prozessnormen darstellt. Zum anderen wird ein einmal etabliertes QMS ungern überarbeitet, hat es sich doch bei der erfolgreichen Zulassung von Produkten und der Vermei-dung oder Beschwichtigung von Rügen der Auditoren vielfach bewährt. Auch wenn eine projektspezifische Anpassung des Vor-gehens vom QMS vorgesehen ist, unterbleibt diese doch meist aus Scheu vor dem Aufwand und aus Angst, die Zulassung zu verpatzen. Innerhalb der sequenziell zu absolvierenden Projekt-phasen ist aber ein iterativ-inkrementelles Vorgehen möglich und sinnvoll: „Unter der Haube“ des sequenziellen Vorgehens werden die zu produzierenden Dokumente iterativ-inkrementell erstellt. Herausforderung sicherheitsbezogenes System Wä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önnen sich deutlich im für den Anwender sichtbaren Verhalten des Sys-tems niederschlagen. Beispielsweise sind die Tonfolgen der Alarmsignale von Infusionspumpen in einer Produktnorm präzise definiert. Die Mehrheit der Anforderungen bezieht sich aber auf technische Details der Umsetzung, beispielsweise die Wider-standsfähigkeit gegen elektromagnetische Immissionen, Über-spannung, Stürze oder Maßnahmen zum Schutz von Mensch und Umwelt. Primäres Ziel der Regulierung und der einzuhaltenden Nor-men und Vorschriften ist die Gewährleistung der Sicherheit von Mensch und Umwelt. Gegenstand der Regulierung sind sicher-heitsbezogene Systeme, deren Ausfall oder Störung Mensch und Sensoren Echtzeit Benutzer Schnittstellen eingebettetes System Faktoren, die das Requirements Engineering beeinflussen (Abb.ˇ2) !% iX Developer "/"#$% – Embedded Software © Copyright by Heise Zeitschriften Verlag
  4. 4. Umwelt gefährden kann. Dieser Sicherheitsbezug wirkt sich ver-schiedentlich auf das Requirements Engineering aus. Kein System ist fehlerlos oder gefeit gegen Ausfall oder Fehlbedienung. Risikomindernde Maßnahmen begrenzen Risi-ken auf einem akzeptablen Niveau. Solche Maßnahmen fordern eine bestimmte Art der Konstruktion oder des Verhaltens des Systems. Risikomindernde Maßnahmen sind also zusätzliche, kaum verhandelbare Anforderungen. Im Extremfall ist die Ent-wicklung eines Systems abzubrechen, wenn die Begrenzung der Risiken aus wirtschaftlichen oder technischen Gründen nicht möglich ist. Die Identifizierung und Bewertung von Risiken liegt in der Verantwortung eines Risk Manager, der sich mit dem Umfeld des Systems gut auskennt. Bei der Identifizierung wird er von allen an der Entwicklung Beteiligten unterstützt. Der Entwurf technischer Lösungen zur Risikominderung ist die Aufgabe ei-nes technisch orientierten Safety Engineer. Beide Rollen können je nach Branche eine einzelne oder mehrere Personen erfüllen, erfordern aber aufgrund der nötigen Methodenkenntnisse Spe-zialisten. Diese Spezialisten übernehmen auch die Interpretation der Produktnormen. Mit Blick auf Risiken werden Sicherheitsabfragen gefordert oder 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 und Wege suchen, um die Attraktivitätsnachteile zu minimieren und gleichzeitig die Absicht der Maßnahme zu wahren. Eventuell ist eine Abwandlung der Maßnahme möglich, die weniger unange-nehm ist oder besser mit dem allgemeinen Benutzungskonzept harmonisiert. Zur Entdeckung von Risiken ist nicht nur der Anwendungs-bereich des Systems, sondern auch das System selbst oder der Systementwurf zu analysieren: Was für Störungen oder Ausfälle könnten an Teilen des Systems auftreten? Welche Wirkung hätte das, 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 einheitliche Sprache 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 Anforderungen eher 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 zur Definition 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ät wird also jede Rückfrage wegen Unklarheiten in der Anforde-rungsdokumentation zweimal gestellt werden. Die Zahl der Rückfragen wird auch wesentlich höher sein, weil jedes Ent-wicklerteam sichergehen will, die Anforderungen genau gleich verstanden zu haben wie die anderen Teams. Da auch viel Wert auf eine Unabhängigkeit des Testens gelegt wird, kommen die Tester noch mal mit den gleichen Fragen, statt sich mit einem Entwickler über das gewollte Verhalten abzusprechen. Lücken in 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. Onlinequellen [a] ISO/IEC "'#$#:"#$$, Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=&'(&& [b] Object Management Group; Unified Modelling Language www.uml.org [c] Karl E. Wiegers; Writing Quality Requirements www.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? Fazit Eingebettete Systeme – besonders im regulierten Umfeld – haben ihre 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 von Anforderungen bleiben dieselben: Korrektheit, Machbarkeit, Notwendigkeit, Priorisierung, Eindeutigkeit und Testbarkeit. Da sich die Entwicklung eingebetteter Systeme eher länger hinzieht, 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. Jede hierauf verwendete Minute spart ein Vielfaches an Aufwand im weiteren Projektverlaufˇ[c]. Weitere Methoden zur Validierung von Anforderungen sind werkzeuggestützte Prüfungen, formale Verifizierung 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 wie die 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 sicherheitskritischer und eingebetteter Systeme. Alle Links: www.ix.de/ix!"!"#$% x iX Developer "/"#$% – Embedded Software !' © Copyright by Heise Zeitschriften Verlag

×