Serie „Requirements Engineering für KMU“ – Teil 11 Requirements Engineering – Finale Überprüfung: Wurde auch nichts vergessen?

Anbieter zum Thema

Heitec AG

MicroConsult Academy GmbH

emlix GmbH

Parasoft® Deutschland GmbH

Die bisherigen Teile haben sich umfangreich und in mehreren Dimensionen mit der Erhebung und Dokumentation von Anforderungen im Requirements Engineering befasst. Dieser abschließende Teil befasst sich nun mit einem finalen Check der erstellten Sammlung von Anforderungen, um sicherzugehen, dass kein wichtiger Aspekt vergessen wurde.

Die Anforderungsspezifikation bzw. das Lastenheft ist eines der wichtigsten Dokumente, vor allem wenn die Entwicklung außer Haus erfolgen soll. Eine präzise, eindeutige, konsistente Formulierung und eine vollständige Erfassung aller Anforderungen ist notwendig, um Unstimmigkeiten zwischen den beteiligten Parteien im Projektverlauf zu vermeiden.

In dieser Folge beleuchten wir nochmals einige Punkte, die unbedingt in die Anforderungsspezifikation mit einfließen sollten:

Einsatzzweck

Weit oben in der Anforderungsspezifikation sollte der Einsatzzweck und alle damit zusammenhängenden Ziele definiert werden. Hierbei wird zunächst festgelegt, wie und wo das Produkt verwendet werden soll, beispielsweise in welcher Branche, wie der Industrie, Medizintechnik oder dem Consumer-Markt. Es ist festzuhalten, welchen Zweck es erfüllen, in welchem Modi (Regelbetrieb, Service, Notbetrieb u. a.) es betrieben wird und wer auf welche Weise mit dem System interagieren wird.

Markt und Zulassung

Erfolgt die Entwicklung für globale Märkte, stellt sich unter anderem die Frage, welche Anforderungen erfüllt werden müssen, um den Marktzugang in EU, USA oder anderen Zielmärkten zu erhalten. Sind alle Märkte aufgelistet und damit verbundene, geltende Normen erfasst? Ist festgehalten, ob Lizenzzeichen (GS, UL, NRTL, CSAUL o. a.) erforderlich sind?

Den Lebenszyklus im Blick

Soll ein Produkt entwickelt werden, welches über einen langfristigen Zeitraum von 10 Jahren oder mehr fertigbar sein soll - was im Industriebereich häufig der Fall ist – müssen die Anforderungen an eben diese Dauer des Produktlebenszyklus definiert werden. Mögliche Aktivitäten zur Unterstützung und Verlängerung des Produktlebenszyklus sind entsprechend zu diskutieren und in den Projektvertrag aufzunehmen. Zudem ist die Frage zu klären, wie im Falle der Abkündigung von im System verbauten Komponenten ein Obsoleszenz-Management aussehen sollte.

Auch die Wartung und Pflege von Software über den Produktlebenszyklus sollte thematisiert werden, Stichwort IT-Security.

Alle an die Entwicklung anschließenden Lebenszyklus-Phasen des Produkts wie Produktion, Betrieb, Wartung, Reengineering/Upgrade und Entsorgung sollten betrachtet werden.

Hardware

Sind Kernkomponenten wie CPU oder Mikrocontroller identifiziert und deren Leistung für den Einsatzzweck ausreichend? Sollten Tests / ein Proof of Concept beispielsweise mit Evaluierungsboards durchgeführt werden?

Sind interne und vor allem externe Schnittstellen präzise definiert? Dies umfasst Schnittstellen zum Fluss von Informationen, Energie oder auch Stoffen/Material. Häufige Fehler und Stolpersteine sind Typen und Belegungen von Steckverbindern und die Kompatibilität von Protokollen zwischen Systemen.

Mechanik

Im Bereich Mechanik sind Kriterien wie physikalische Grenzen (z. B. Gewicht, Form-/Passungsfaktoren) des Systems zu beachten. Es ist darauf zu achten, ob mechanische Schnittstellen/Montageschnittstellen zu interagierenden Systemen und Hostplattformen außerhalb der Systemgrenzen definiert sind.

Welche Vorgaben bzgl. des funktionalen oder ästhetischen Designs der Mechanik müssen eingehalten werden? Wie interagiert das System mit seiner Umgebung, welchen Kühlbedarf, welche Einschränkungen und Betriebsbedingungen gibt es, existieren z. B. Anforderungen an die Schock- und Vibrationsfestigkeit?

Software

Nach Hardware und Mechanik ist der Entwicklungsumfang der operativen Software für das Produkt festzulegen. Hier können Diagramme und Modelle zu Daten, Struktur und Ablauf wertvolle Dienste leisten (siehe Teil 7 dieser Serie). Des Weiteren müssen Softwareschnittstellen mit interagierenden Systemen definiert werden. Anforderungen zu Feld-/Remoteupdates, Verfügbarkeit und in steigendem der Maße IT-Sicherheit müssen betrachtet werden.

Auch muss definiert werden, ob und welcher Software-Entwicklungsumfang für Typ- und Serientests nötig ist.

Typtest

Beim Typtest wird ein repräsentatives Muster eines Produkts einer umfassenden Reihe von Tests unterzogen, um seine Übereinstimmung mit den Anforderungen zu überprüfen. Er wird während der Entwicklungsphase durchgeführt.

Alle Anforderungen aus der Anforderungsspezifikation sollten selbstverständlich im Rahmen eines Typtests oder mit anderen Methoden verifiziert werden können. Hierzu zählen beispielsweise Anforderungen zu Umweltbedingungen wie Temperatur, Luftfeuchtigkeit, Schock, Vibration oder auch EMV.

Aber auch aus dem Typtest selbst können Anforderungen erwachsen. Je nach Art und Weise wie die einzelnen Testfälle umgesetzt werden, können sich Anforderungen auf die Gestaltung des Systems ergeben. Beispielsweise können zusätzliche Interfaces die Durchführung von Tests erleichtern.

Darüber hinaus ist Einverständnis zu Umfang und Testtiefe elektrischer Qualifizierungstests (z. B. Signalintegrität, Ripple DC/DC-Wandler, etc.) herzustellen („Erwartungsmanagement“). Hohe Testtiefen sorgen für zuverlässigere, qualitativ hochwertigere Produkte, verursachen jedoch auch mehr Aufwände und Kosten. In diesem Zusammenhang sei auf die HEITEC-Beitragsreihe über die Qualifizierung von Schaltnetzteilen verwiesen. Außerdem ist zu beachten, ob Umfang und Verantwortlichkeiten der Integrationstests vereinbart wurden und Vor-Ort-Einsätze beim Kunden notwendig sind. Undefinierte Verantwortlichkeiten sorgen andernfalls für erhöhte Aufwände und Disruption im Projekt.

Häufig werden die neu entwickelten Produkte in größere Systeme integriert. Eine Voraussetzung für Verifikation und Validation ist in diesem Fall die Integration in das Host-System.

Serien- / End-of-Line-Prüfung

Eine End-of-Line-Prüfung wird an jedem Produkt durchgeführt, das die Produktionslinie verlässt. Es soll sichergestellt sein, dass es die festgelegten Leistungs- und Qualitätsstandards erfüllt, bevor es den Kunden erreicht.

Im Gegensatz zum Typtest wird bei der End-of-Line Prüfung nicht jedes Produkt noch einmal gegen alle Anforderungen geprüft. Es sollte jedoch Konsens zwischen den Beteiligten darüber herrschen, welche Funktionalitäten vom End-of-Line Test abgedeckt werden sollen.

Auch sollte abgestimmt werden, welche Prüfmethoden (z. B. automatische optische Inspektion (AOI), Flying Probe, Boundary Scan, Funktionstests) zum Einsatz kommen sollen und ob Anforderungen zur Testabdeckung pro Baugruppe (welcher Prozentsatz der Bauteile getestet wird) oder Testabdeckung pro Batch (ob stichprobenartig oder 100%) bestehen.

Zudem können aus der End-of-Line Prüfung selbst Anforderungen erwachsen. Je nach Art und Weise wie die einzelnen Prüfschritte umgesetzt werden, können sich Anforderungen auf die Gestaltung des Systems ergeben. Beispielsweise können zusätzliche Testpunkte oder Interfaces oder spezielle mechanische Eigenschaften des Systems die Durchführung der End-of-Line Prüfung erleichtern und wertvolle Zeit und Kosten bei der Serienfertigung sparen.  (sg)

Serie „Requirements Engineering für KMU“ – Teil 1

Requirements Engineering: Grundlage für erfolgreiche Projekte in KMU

Serie „Requirements Engineering für KMU“ – Teil 2

Anforderungstypen im Requirements Engineering

* Stefan Lange ist Teamleiter Systems Engineering im HEITEC Geschäftsgebiet Elektronik und Dozent für Systems Engineering an der Hochschule Augsburg.

* Moises Lorenzo-Leon ist Systemingenieur im HEITEC Geschäftsgebiet Elektronik und Certified Professional für Requirements Engineering.

(ID:50696384)