SysAssist by Kosterski Engineering
PLBook a call

Automotive SPICE · SYS.1 · SYS.2 · SYS.3 · test case drafts

Less rewriting requirements. More systems engineering.

SysAssist works directly in your ALM along Automotive SPICE SYS.1, SYS.2 and SYS.3: it decomposes stakeholder requirements into system requirements, reviews the ones you already have, and drafts test cases from what you approve. Every suggestion waits for your decision — and every decision is recorded on the item itself.

Book a pilot call Follow one requirement

Works in Codebeamer, DOORS / DOORS Next, Polarion and Windchill RV&S

Example: a requirement in your ALM, reviewed by SysAssist, with three findings waiting for your decision.
SYS-REQ-0442 · rev. 3 3 findings

“The system should1 respond quickly2 to the parking sensor signal3.”

  1. 1

    “Should” is not binding — requirements are written with “shall”.

    wording · ISO/IEC/IEEE 29148 · confidence: high

  2. 2

    “Quickly” cannot be verified. Suggested: “within ⟨t⟩ ms” — you set the value.

    SYS.2.BP3 · verifiability · confidence: high

  3. 3

    Which sensor, which signal? No reference to an interface definition.

    SYS.3 · interfaces · confidence: medium

Your decision is saved as a comment on SYS-REQ-0442.

Your Tuesday, before and after

Not the whole job — the repetitive part that eats the most hours.

Tuesday today

  1. Three hours reading 80 requirements for a new module
  2. Marking unclear wording by hand in Excel
  3. Rebuilding traceability because a link got lost
  4. Starting to break the new customer spec down into system requirements — from scratch
  5. Writing questions for the customer, because there was no time earlier

Tuesday with SysAssist

  1. Going through ambiguities that are already flagged
  2. Approving the drafted decomposition of the new customer spec into system requirements
  3. Customer questions ready to send before lunch
  4. Approving proposed trace links, so traceability stays current
  5. The rest of the day: architecture, not rewriting

Stays with you

  • Approving every change before it reaches your ALM
  • Architecture decisions — it proposes options, you choose
  • Talking to the customer — questions come to you first
  • Closing a requirement as verified

Where it works in the V

On the left side it drafts and reviews — from customer requirements down to the architecture. On the right side it drafts test cases from what you have approved.

SYS.1 Requirements elicitation SYS.2 System requirements SYS.3 System architecture decomposes allocates SYS.5 System verification SYS.4 Integration verification SWE · HWE not in scope test case drafts you approve test case drafts you approve where SysAssist works every draft waits for your approval
On the left side of the V, SysAssist decomposes and reviews requirements (SYS.1, SYS.2, SYS.3); on the right side it drafts test cases (SYS.4, SYS.5). Every draft waits for your approval.
SYS.1

Requirements elicitation

Consolidates stakeholder requirements scattered across documents and drafts clarifying questions where the intent is unclear.

SYS.2

System requirements

Decomposes stakeholder requirements into system requirement drafts with trace links, and checks existing ones for completeness, unambiguity and verifiability.

SYS.3

System architecture

Proposes the allocation of system requirements to architecture elements and flags interfaces that are not yet defined.

SYS.4 · SYS.5

Test case drafts

Drafts test cases from approved requirements and interfaces — preconditions, steps, expected results — each traced back to its source.

From customer requirement to system requirements

SysAssist doesn’t only check what already exists. It decomposes a stakeholder requirement into system requirement drafts — and leaves the values only you can know for you to fill in.

STK-REQ-017 · customer specSYS.1

“The driver must be warned of obstacles when parking at low speed.”

System requirement draftsSYS.2
  • SYS-REQ-0450The system shall activate obstacle detection when reverse gear is engaged or vehicle speed is below ⟨v⟩ km/h.Draft
  • SYS-REQ-0451The system shall detect obstacles between ⟨min⟩ and ⟨max⟩ cm from the rear bumper.Draft
  • SYS-REQ-0452The system shall issue an acoustic and a visual warning when an obstacle is detected.Draft
  • QuestionFor the customer: what speed counts as “low speed”?Waits for you

Each draft traces back to STK-REQ-017. The values in ⟨ ⟩ are yours to set; the question reaches the customer only after you approve it.

One requirement, from finding to test case

The requirement from the top of this page, followed through to the end.

  1. Step 1 of 3

    You decide

    Accept, edit or reject each finding. You add what the model cannot know — here, the response time agreed with the customer.

    Review · SYS-REQ-04423 of 3 decided
    • 1“should” → “shall”Accepted
    • 2“quickly” → “within 200 ms”“Agreed with the customer in the kick-off minutes.”Accepted · edited
    • 3Sensor signal — no change“Interface specified in SYS-ARC-0027, already linked.”Rejected

    Rev. 4“The system shall respond to the parking sensor signal within 200 ms.”

  2. Step 2 of 3

    It records the decision on the item

    Changes reach your ALM only after your approval. The finding, your decision and your rationale are saved as comments on the requirement itself — clean decision traceability for reviews and assessments, with no separate log to keep.

    Comments · SYS-REQ-04423
    • SysAssist09:14

      Raised 3 findings: wording (ISO/IEC/IEEE 29148), verifiability (SYS.2.BP3), interface (SYS.3).

    • You09:41

      Accepted 1 and 2, t = 200 ms per the kick-off minutes. Rejected 3: interface specified in SYS-ARC-0027.

    • SysAssist09:41

      Change applied after approval: rev. 3 → rev. 4.

  3. Step 3 of 3

    It drafts the test cases

    From the approved requirement, SysAssist drafts test cases for system verification, each traced back to its source. You review and approve them like everything else.

    Test case drafts · SYS-REQ-0442 rev. 4SYS.5
    • TC-0442-01Sensor signal received → response within 200 msDraft
    • TC-0442-02Same, at maximum bus load → response within 200 msDraft
    • TC-0442-03No sensor signal → no response (negative case)Draft

    Each draft traces back to SYS-REQ-0442 and reaches your test management only after you approve it.

For engineering managers: time and capacity

Where the hours come back — and how the pilot proves it on your own requirements.

pilot target

−50%

time spent reviewing requirements documentation

pilot target

+50%

inconsistencies found before the formal review

  • The first pass is done before the review starts

    Every requirement is read, checked and annotated before an engineer opens the document. Reviews start from a list of findings, not from raw text.

  • Fewer late defects

    Ambiguities and missing interfaces surface in SYS.2 and SYS.3 — not in integration testing, where rework costs the most.

  • Senior time on senior work

    Decomposition drafts, trace links and test case drafts arrive ready for approval. Your most experienced engineers spend their time on architecture decisions.

  • Faster assessment preparation

    The decision history already sits on each item, so less time goes into assembling evidence before an ASPICE assessment.

  • No new headcount, no new tool

    It works in your existing ALM — no migration and no new system to maintain.

How we measure it. Before the pilot we record your baseline — review hours, findings per phase, rework after review. After the pilot we compare on the same kind of work. The figures above are pilot targets, not results.

Your first week

Read-only first. Your process doesn’t change until you decide it should.

  1. Day 1

    Read-only connection to your ALM. Nothing changes in your daily work yet.

  2. Days 2–3

    The first findings arrive in your review queue — you assess them at your own pace, alongside normal work.

  3. End of week

    Together we agree which tasks are worth handing over and which stay fully manual.

Technical questions

Does SysAssist replace a systems engineer?

No. SysAssist prepares, you decide. Every suggestion waits in a review queue — nothing is written to your ALM without an engineer’s approval.

Does it only review, or does it also write requirements?

Both. It decomposes stakeholder requirements into system requirement drafts (SYS.1 → SYS.2), proposes their allocation to architecture elements (SYS.2 → SYS.3), reviews existing requirements and drafts test cases. Everything it drafts waits for your approval.

What if the model is wrong?

You reject the finding with one click and a short rationale. Every finding shows the rule and the evidence it is based on, so it is easy to judge — and the rejection is recorded like any other decision.

Where is the decision history kept?

On the item itself, as comments in your ALM: the finding, the decision and the rationale. There is no separate log to maintain — and in an assessment, the “why” sits right next to the requirement.

Does it create test cases on its own?

It drafts them from approved requirements. A draft stays a draft until you review and approve it — nothing is created in your test management without you.

Where does our data physically live?

Depending on what we agree — integration with an AI engine already present in your organization (e.g. Copilot) or a fully on-premise deployment.

What does the first step look like?

A short, paid pilot on a narrow, agreed task — with clear success criteria set before the start.