Requirements management
without an ALM rollout

OEM spec, your requirements and tests in one chain. Stale evidence turns orange. Four-week pilot, no DOORS project.

Book a briefing Start the demo
Voice platform, software supplier3 of 4 closed
  1. Spec §7.2.3Wake-word responseSYS-0142Detect ≤ 300 msOK
  2. SYS-0142Detect ≤ 300 msSWE-0088On-board + offlineOK
  3. SWE-0088On-board pathTest 0407Bench, 5 languagesOK
  4. CR-19Customer: 250 ms not 300-no re-verificationGap
Orange = missing link or stale evidence. Demo data

Excel works until someone asks which evidence covers which requirement

As long as a program is running, Excel carries surprisingly far. Requirements sit in the customer requirements specification (OEM spec), your own specification lives in Word or Confluence, work runs through Jira, tests sit in the test team’s own lists. Everyone knows their slice. Nobody owns the chain.

It gets expensive when the customer tightens requirements, when the assessment starts, and when someone leaves the team. The question is always the same: which requirement is covered by which evidence in which version? Ticket history does not answer that.

You do not need a new tool landscape for that. You need one place where OEM spec page, requirement and evidence sit together, and gaps turn orange.

Where it breaks today

  • Two requirements, one line. A second requirement hides after the semicolon. In Excel it never gets its own ID.
  • Standard without a clause. “ASPICE-compliant” or “per ISO/SAE 21434” is an intention, not evidence.
  • The change lives only in email. CR-19 tightens 300 ms to 250 ms. The Jira ticket closes. The test case stays on the old value.
  • Evidence with no version anchor. The test was green against a specification version that no longer exists. The result can still be true. The evidence is stale.
  • The assessment starts at the evidence. The assessor wants the path back to the OEM spec page.

Hands-on: Take your current OEM spec and the latest customer change request. If you cannot say within five minutes which test cases are affected, that is the gap this page is about.

Already on Polarion or DOORS? Then: Requirements management beside an existing ALM system.

Documents, ALM, or a coverage chain

Excel & documents

  • RolloutImmediate
  • ChangeMail, reminder, new ticket
  • Stale evidenceNo state
  • Source of truthA person

Classic ALM (DOORS, Polarion, codebeamer)

  • RolloutQuarters: IT, licenses, process
  • ChangeCR object; evidence often stays green
  • Stale evidenceUsually no dedicated state
  • Source of truthThe ALM project

Cevelar

  • RolloutDays to weeks, per program
  • ChangeIngest delta, mark evidence stale
  • Stale evidenceOwn state in the matrix
  • Source of truthSpec and evidence state; export anytime

From folder to orange gap

Left is today. Right is what sits in the matrix after the pilot.

Today, no tool3 gaps
  • SpecificationConfluence and PDF, no stable IDs
  • ChangeChange request in email, test stays old
  • EvidenceGreen against a spec version that no longer exists
Orange = missing link or stale evidence
With Cevelar, after the pilotChain readable
  • SpecificationRequirement with ID, page and acceptance criterion
  • ChangeA tightened customer requirement creates a visible gap
  • EvidenceEvidence age and baseline sit in the matrix
Structure as the outcome

In-car assistant, three customer programs

Voice assistance for three OEMs. Development in Jira, spec in Confluence, tests in Excel and on the bench, OEM spec as PDF. No requirements-management tool. Figures are demo data.

  • ProgrammeAssistant platform, 3 variants
  • BaselineOEM spec Rev. C, 214 requirements
  • Covered187 with evidence
  • Gaps14 without re-verification after CR-19
  • No method13 without a defined verification method
SYS-0142, fields1 gap
  • SourceOEM spec Rev. C, §7.2.3, page 47
  • RequirementWake-word ≤ 300 ms, on-board, offline
  • SoftwareSWE-0088, on-board + offline path
  • VerificationTest 0407, bench, 5 languages
  • CR-19250 ms required, no re-verification
Orange = missing link or stale evidence. Demo data

What happens in the week of CR-19

  1. Customer mail arrives CR-19 is filed in Jira. Confluence and Excel stay on 300 ms.
  2. Ticket is Done Software is updated. Acceptance criterion and bench test are not rebound.
  3. Orange becomes visible SYS-0142 shows as a gap. The matrix lists every requirement that still needs re-verification.
  4. Engineers judge Adapt the test, duplicate it, or document a deviation. Cevelar shows the break before the bench is booked.

A second case does not change the requirement at all. If a shipped feature depends on a model that updates in the field, yesterday’s bench result can still be true and still be stale. Evidence hangs on the model version as the anchor, not only on the requirement text. Ticket systems and classic ALM do not treat that as a first-class evidence state.

Demo data. Orange only means: missing link or stale evidence.

  1. Pick a program Day 1 Action: Choose one program with a customer document and live changes.
    Outcome: Name and owners are fixed.
  2. Assemble the baseline Day 1-3 Action: OEM spec, internal specs, open change requests and annexes into one folder. Label e.g. Rev. C + CR-19. No cleanup first.
    Outcome: One baseline as the starting point.
  3. Extract requirements Week 1 Action: Upload PDF, Word and Excel. Cevelar splits prose, separates twin requirements, assigns IDs with page references.
    Outcome: First ID list to check against the PDF.
  4. IDs and acceptance criteria Week 2 Action: Each requirement gets an acceptance criterion, a verification method and an owner. Engineers sharpen disputed items.
    Outcome: Orange count: requirements without a verification method.
  5. Attach standards and process Week 3 Action: Attach ASPICE, ISO/SAE 21434, UNECE R155/R156 and OEM-specific constraints to the requirement, not to a folder.
    Outcome: Critical requirements show clause and verification method.
  6. Close the change loop from week 4 Action: Re-ingest every customer delta, read the matrix, plan re-verification before bench or vehicle is booked.
    Outcome: Baseline with history, defensible in an assessment.

Pilot: one program, four weeks, close orange gaps

No IT ticket. You bring a live program and measure what turns orange. Built by test and validation engineers. Who we are

What you measure3 numbers
  • No methodRequirements without a verification method, start vs end
  • Re-verificationTime from customer delta to impact list
  • Audit sampleSample from the matrix without rework
Start vs end of the four weeks
What you bring4 points
  • 01One program with a customer documentOK
  • 022-4 hours/week requirements engineeringOK
  • 03Someone with decision rightsOK
  • 04No IT integration in the pilotOK
Start from as-is

Hard stop

If after four weeks no defensible gap has become visible, the pilot was the wrong tool. We will say so. Check in week two: pull three requirements from the matrix and name the page, the acceptance criterion and the verification method without follow-up questions.

Evidence first, tool second.

No tool selection, no IT portfolio. One spec baseline, the next customer change request, one coverage matrix. Hosted in Germany or on your premises.

FAQ

Questions on starting without a tool

What teams without a requirements-management tool clarify before the pilot.

We do not have a requirements-management tool yet. Is Cevelar the wrong product?

The opposite. Without legacy, you skip the hardest part of any rollout: migration. You start from the document you already have and get structure as an outcome, not a prerequisite.

Do we still need an ALM system?

Not for requirements, evidence and coverage. If you run development tasks in Jira, that stays. Cevelar does not replace task management. If the OEM later mandates a specific ALM system, the requirement set moves there via the ReqIF exchange format. Already on Polarion or DOORS? See Requirements management beside an existing ALM system.

How do we get out again?

Requirements, links and evidence states can be exported as the ReqIF exchange format and Excel at any time. The work remains yours.

Who maintains this day to day?

In the pilot, two to four hours per week in requirements engineering. The point of the platform is that states are derived, not curated: when a customer document is updated, the system marks affected evidence itself.

How does this relate to ASPICE?

ASPICE requires bidirectional traceability between customer requirement, system requirement, software and test, plus a recoverable change history. Cevelar produces that chain as a by-product of daily work instead of as assessment prep. Only you can pass an assessment. The platform supplies the evidence. Details: ASPICE guide.

Where do our documents live?

Hosted in Germany or on your premises. Customer documents stay in your tenant; roles and visibility are controllable per program. Customer documents are not used to train models.

What about standard texts?

Freely available rule sets such as EU regulations and UNECE regulations are included. Paid standards you bring under your own license. We do not resell standard texts.

What does entry cost?

We do not publish a list price. The pilot is a bounded program with a fixed duration. An engineer on the program, not a tool rollout in the IT portfolio.

Application & traceability

All use cases

Pilot on a real spec baseline.

One program, one OEM spec, four weeks. Book a briefing or start the demo. We reply in person.

Book a briefing Start the demo