Use Case · Requirements

Modernes Requirements Management mit Cevelar

Wie ein Automotive-Zulieferer Spec, Software-Anforderungen und Tests in einer Kette hält — statt Excel neben Polarion und Hoffnung vor dem ASPICE-Assessment. Konkrete Anleitung, konkretes Beispiel.

Gespräch buchen Demo starten

Stabile IDs aus der Spec
Lücken vor dem Assessment
Export in Polarion/Jira

BMS Soft · Tier-1 Zulieferer3 von 4 geschlossen

OEM §5.4.1Cell undervoltageSYS-REQ-0142UV detect ≤ 20 msOK
SYS-REQ-0142UV detect ≤ 20 msSWE-REQ-0088ISR Path AOK
SWE-REQ-0088ISR Path ATC-0407HIL UV rampOK
CR-19OEM: 15 ms statt 20—kein Re-VerifyLücke

Auszug · Demo-Daten · Soft-Zulieferer

Kontext

Was „modernes“ Requirements Management hier heißt

Nicht mehr Tickets pflegen. Jede Pflicht hat eine stabile ID, eine Spec-Seite, eine Klausel, eine Verification Method und einen sichtbaren Zustand: gedeckt, teilweise oder Lücke. Abdeckung ist kein Gefühl — sie ist eine Matrix.

Bei Automotive-Zulieferern sitzt Requirements Management zwischen OEM-Lastenheft, interner System-/Software-Spec und dem ALM (Polarion, Jira, DOORS). Das ALM speichert Tickets hervorragend. Extrahieren, zerlegen und Lücken finden tut es nicht. Genau dort setzt Cevelar an — als Coverage-Schicht vor und neben dem ALM, nicht als Ersatz.

Wo es heute bricht

Zwei Sprachen, eine Zeile. Die zweite Pflicht steht nach dem Semikolon und landet nie als eigene ID.
Norm ohne Abschnitt. „Nach ISO 26262“ oder „ASPICE-konform“ ist keine Traceability.
Change nur in der Mail. CR-19 verschärft 20 ms auf 15 ms. Polarion kennt den Ticket-Status. Die Spec-Seite und der Testfall nicht.
Assessment startet bei der Evidenz. Der Assessor will den Pfad zurück zur Seite — nicht den Screenshot einer grünen Zelle.

Noch kein RM-Tool? Dann: Requirements Management einführen ohne ALM.

Verwandt: Prüfplan aus OEM-Lastenheft, ASPICE Traceability.

Wirkung

Die Kette hält, bevor das Assessment sie prüft.

Spec → ID → Test Bidirektional, nicht nur im Ticket

Change → Gap OEM-Deltas erzeugen sichtbare Lücken

ALM-Export Polarion/Jira bleiben System of Record

Beispiel · Soft-Zulieferer

BMS-Software bei einem Tier-1

Ein laufendes Programm: OEM-Lastenheft für den HV-Energiespeicher, interne SWE-Spec, Polarion als ALM, HIL-Tests im eigenen Labor. Cevelar liest Spec und CR-Mails, hält die Coverage, Polarion behält die Tickets.

ProgrammHV-BMS Soft · Soft-ASIL B
BaselineOEM LH Rev C · 214 Pflichten
Gedeckt187 mit Testfall
Lücken14 ohne Re-Verify nach CR-19
ALMPolarion · Export wöchentlich

SYS-REQ-0142 · Felder1 Gap

QuelleOEM LH Rev C · §5.4.1 · S.47
PflichtUndervoltage Detection ≤ 20 ms
SW-ChildSWE-REQ-0088 · ISR Path A
VerificationTC-0407 · HIL UV ramp
CR-1915 ms gefordert · Re-Verify fehlt
ASPICESYS.2 · SWE.1 · SWE.5

Orange = fehlende Verknüpfung · Demo-Daten

Lesen des Boards

Was das Beispiel zeigt

SYS-REQ-0142 ist sauber: Spec-Seite, Child-Requirement, Testfall. Der Bruch sitzt im Change. CR-19 verschärft die Zeit auf 15 ms — ohne dass TC-0407 neu gebunden wurde. Polarion zeigt vielleicht ein offenes Ticket. Die Coverage-Matrix zeigt eine orange Lücke.

Genau das ist modernes Requirements Management mit Cevelar: Die Wahrheit hängt an der Spec und am Gap-Zustand, nicht am Ticket-Workflow. Engineers entscheiden, ob der Test angepasst, dupliziert oder als Ausnahme dokumentiert wird. Die Plattform macht nur sichtbar, was sonst untergeht.

14 von 214 Pflichten ohne Re-Verify nach einem OEM-Delta — billig im Sprint, teuer im Assessment.

Baseline und Deltas sammeln Aktuelles OEM-Lastenheft, interne System-/SW-Spec, offene Change-Requests und Mail-Anhänge. Ein Ordner, eine Baseline-Kennung (Rev C + CR-19).
Pflichten extrahieren Cevelar liest PDF/DOCX/XLSX, zerlegt Prosa und Tabellen, trennt Sätze mit zwei Pflichten. Mehrsprachige Specs sind der Normalfall.
IDs und Acceptance festziehen Jede Pflicht bekommt eine stabile ID, Spec-Seite und Acceptance Criterion. Engineers schärfen Formulierungen — die Plattform skaliert die Masse.
Normen und ASPICE mappen Klauseln (ISO 26262, OEM-Härten) und Prozess-Treffer (SYS.2, SWE.1, SWE.5) anbinden. Was ohne Verification Method bleibt, ist orange.
In Polarion/Jira exportieren Nur neue und geänderte IDs, mit Quellenverweis. ALM bleibt System of Record. Cevelar bleibt Source of Coverage.
Change-Loop schließen Jedes OEM-Delta erneut einspielen. Gap-Matrix lesen. Re-Verify planen, bevor Samples oder HIL-Schichten gebucht sind. Optional: Arc für parallele Lab-Kampagnen.

Abgrenzung

ALM allein vs. mit Cevelar

Polarion / Jira / DOORS allein

StärkeTickets, Baselines, Workflows
LückeExtrahiert Specs nicht
RisikoChanges ohne Spec-Seite

Cevelar + ALM

StärkeSpec → ID → Gap → Export
LückeMacht fehlende Links sichtbar
RolleCoverage-Schicht, kein ALM-Ersatz

Für Heads of Requirements & Software

Weniger Assessment-Nacharbeit. Mehr Spec-Wahrheit.

Der Pilot braucht keine neue Tool-Landschaft. Eine Spec-Baseline, das nächste OEM-Delta, eine Gap-Matrix. Engineers urteilen, wo Formulierungen strittig sind. Cevelar skaliert den Rest — EU-gehostet, exportfähig in euer ALM.

FAQ

Fragen zum Einsatz

Was Teams vor dem Pilot klären.

Ersetzt Cevelar Polarion, Jira oder DOORS?

Nein. Cevelar extrahiert, mappt und macht Lücken sichtbar. Polarion und Jira bleiben das System of Record für Tickets, Baselines und Workflows. Der Export landet dort, die Coverage-Wahrheit bleibt an der Spec.

Wo startet man in einem laufenden Programm?

Mit einem Pilot auf einer Spec-Baseline und dem nächsten OEM-Delta: Lastenheft plus Change-Mails hochladen, Gap-Matrix lesen, nur die Lücken in Polarion nachziehen. Nicht das ganze Backlog umziehen.

Was ist der erste sinnvolle Pilot bei einem Automotive-Zulieferer?

Eine Software- oder System-Spec mit Normbezug und Change-Druck: BMS, Inverter-Steuerung, Onboard-Charger. Genug Komplexität für Traceability, klein genug für einen Sprint.

Wie hängt das mit ASPICE zusammen?

ASPICE verlangt bidirektionale Traceability Spec → REQ → Test → Evidenz. Cevelar hält die Kette an der Quelle und markiert Brüche, bevor das Assessment sie findet. Details: ASPICE-Leitfaden.

Bleiben Specs und Deltas beim Kunden?

Ja. Verarbeitung EU-gehostet in Frankfurt. Cevelar trainiert keine öffentlichen Modelle mit euren Lastenheften.

Kontakt

Pilot an einer echten Spec-Baseline.

Gespräch buchen oder Demo starten. Wir antworten persönlich.