Use case · Requirements

Modern requirements management with Cevelar

How an automotive supplier keeps spec, software requirements and tests in one chain — instead of Excel beside Polarion and hope before the ASPICE assessment. Concrete guide, concrete example.

Book a briefing Start demo

Stable IDs from the spec
Gaps before assessment
Export to Polarion/Jira

BMS Soft · Tier-1 supplier3 of 4 closed

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 not 20—no re-verifyGap

Excerpt · demo data · software supplier

Context

What “modern” requirements management means here

Not more ticket hygiene. Every duty has a stable ID, a spec page, a clause, a verification method and a visible state: covered, partial or gap. Coverage is not a feeling — it is a matrix.

At automotive suppliers, requirements management sits between the OEM lastenheft, the internal system/software spec and the ALM (Polarion, Jira, DOORS). The ALM stores tickets well. It does not extract, split or find gaps. That is where Cevelar sits — a coverage layer before and beside the ALM, not a replacement.

Where it breaks today

Two languages, one line. The second duty sits after the semicolon and never becomes its own ID.
Standard without a clause. “Per ISO 26262” or “ASPICE-compliant” is not traceability.
Change only in mail. CR-19 tightens 20 ms to 15 ms. Polarion may know a ticket. The spec page and the test case do not.
Assessment starts at evidence. Assessors want the path back to the page — not a screenshot of a green cell.

No RM tool yet? Then: Introduce requirements management without an ALM.

Impact

The chain holds before the assessment checks it.

Spec → ID → Test Bidirectional, not only in the ticket

Change → Gap OEM deltas create visible gaps

ALM export Polarion/Jira stay system of record

Example · software supplier

BMS software at a Tier-1

A live programme: OEM lastenheft for the HV energy store, internal SWE spec, Polarion as ALM, HIL tests in-house. Cevelar reads the spec and CR mails, holds coverage; Polarion keeps the tickets.

ProgrammeHV-BMS Soft · Soft ASIL B
BaselineOEM LH Rev C · 214 duties
Covered187 with a test case
Gaps14 without re-verify after CR-19
ALMPolarion · weekly export

SYS-REQ-0142 · Fields1 gap

SourceOEM LH Rev C · §5.4.1 · p.47
DutyUndervoltage detection ≤ 20 ms
SW childSWE-REQ-0088 · ISR Path A
VerificationTC-0407 · HIL UV ramp
CR-1915 ms required · re-verify missing
ASPICESYS.2 · SWE.1 · SWE.5

Orange = missing link · demo data

Reading the board

What the example shows

SYS-REQ-0142 is clean: spec page, child requirement, test case. The break sits in the change. CR-19 tightens the time to 15 ms — without rebinding TC-0407. Polarion may show an open ticket. The coverage matrix shows an orange gap.

That is modern requirements management with Cevelar: truth hangs on the spec and the gap state, not on the ticket workflow. Engineers decide whether to adapt, duplicate or exception the test. The platform only makes visible what otherwise sinks.

14 of 214 duties without re-verify after an OEM delta — cheap in the sprint, expensive in the assessment.

Collect baseline and deltas Current OEM lastenheft, internal system/SW spec, open change requests and mail attachments. One folder, one baseline tag (Rev C + CR-19).
Extract duties Cevelar reads PDF/DOCX/XLSX, splits prose and tables, separates sentences with two duties. Mixed-language specs are the normal case.
Lock IDs and acceptance Every duty gets a stable ID, spec page and acceptance criterion. Engineers sharpen wording — the platform scales the volume.
Map standards and ASPICE Bind clauses (ISO 26262, OEM hardenings) and process hits (SYS.2, SWE.1, SWE.5). Anything without a verification method stays orange.
Export into Polarion/Jira Only new and changed IDs, with source reference. ALM stays system of record. Cevelar stays source of coverage.
Close the change loop Re-ingest every OEM delta. Read the gap matrix. Plan re-verify before samples or HIL slots are booked. Optional: Arc for parallel lab campaigns.

Boundary

ALM alone vs with Cevelar

Polarion / Jira / DOORS alone

StrengthTickets, baselines, workflows
GapDoes not extract specs
RiskChanges without a spec page

Cevelar + ALM

StrengthSpec → ID → gap → export
GapMakes missing links visible
RoleCoverage layer, not an ALM replacement

For heads of requirements & software

Less assessment rework. More spec truth.

The pilot needs no new tool landscape. One spec baseline, the next OEM delta, one gap matrix. Engineers judge where wording is contested. Cevelar scales the rest — EU-hosted, exportable into your ALM.

FAQ

Questions before the pilot

What teams clarify first.

Does Cevelar replace Polarion, Jira or DOORS?

No. Cevelar extracts, maps and makes gaps visible. Polarion and Jira stay the system of record for tickets, baselines and workflows. The export lands there; coverage truth stays on the spec.

Where do you start on a live programme?

With a pilot on one spec baseline and the next OEM delta: upload the lastenheft plus change mails, read the gap matrix, pull only the gaps into Polarion. Do not migrate the whole backlog.

What is a sensible first pilot at an automotive supplier?

A software or system spec with standard references and change pressure: BMS, inverter control, onboard charger. Enough complexity for traceability, small enough for one sprint.

How does this relate to ASPICE?

ASPICE requires bidirectional traceability Spec → REQ → Test → Evidence. Cevelar keeps the chain on the source and marks breaks before the assessment finds them. Details: ASPICE guide.

Do specs and deltas stay with the customer?

Yes. Processing is EU-hosted in Frankfurt. Cevelar does not train public models on your lastenhefte.

Contact

Pilot on a real spec baseline.

Book a briefing or start the demo. We reply in person.