Systems engineering & requirements management (MBSE) assistant

Complex products (vehicles, machines, aircraft, medical and energy systems) carry thousands of requirements spread over documents, requirement tools and system models. Keeping them unambiguous, traceable and consistent is slow expert work. An LLM assistant drafts and rewrites requirements, flags quality defects, proposes trace links and generates or explains model elements, while the engineer remains the author of record. Typical benefit: faster reviews and fewer late-found specification defects, not autonomous design.

Problem & value

• Today: requirements arrive as customer PDFs, standards and emails. Engineers rewrite them by hand into a requirements tool (IBM DOORS family, Siemens Polarion, Jama Connect, Codebeamer, PTC Windchill/Integrity), link them to model elements and test cases, and review them against guidelines such as the INCOSE Guide to Writing Requirements [1]. Defects found late (ambiguity, missing verification method, conflicting values) are expensive.
• AI value: (1) extraction of candidate requirements from long documents, (2) rule- and LLM-based quality checks (ambiguity, passive voice, vague terms, non-atomic sentences, missing units), (3) rewriting into templates such as EARS [2], (4) suggested trace links and coverage gaps, (5) impact analysis on change requests, (6) natural-language access to the model ("which components allocate requirement X?").
• Evidence: vendors and INCOSE working groups report productivity gains in pilots, but no neutral, large-scale quantified benefit study is known to us; measure on your own baseline.
• Enabler: SysML v2 (OMG, with a textual notation and a standard REST/JSON API) makes models machine-readable and far easier for LLMs to read and write than diagram-only SysML v1 [3][4].

Variants

• Requirements-only assistant: quality check, rewriting and trace suggestion in an existing RM tool.
• MBSE assistant: generates/edits SysML v2 or Capella elements, checks model-to-requirement allocation.
• Tender-to-spec: compliance matrix and requirement extraction from RFQs (see DOC-015).
• Safety/regulatory variant: links requirements to hazards and standards (ISO 26262, IEC 62304, DO-178C, EN 50126); the assistant prepares evidence, humans sign off.
• SMB / startup: lightweight Markdown/ReqIF + Git workflow with an LLM review bot.
• Defence/aerospace: same architecture, typically air-gapped; export-control constraints apply.

How it works

1. sources (PDF/Word/ReqIF, standards, RM tool, SysML v2 / Capella model)
2. parsing + chunking (layout-aware, keep clause IDs)
3. indexing (embeddings + keyword + model-element graph)
4. LLM tasks: extract / rewrite (EARS) / quality-check / link / summarise / draft model text
5. deterministic validators (rule engine, SysML v2 parser/API, unit & range checks)
6. proposal queue in RM/MBSE tool (diff, rationale, source citation)
7. engineer review & approval
8. baseline, change record, audit log

• Retrieval over the model: requirements, blocks, ports and interfaces form a graph; hybrid vector + graph retrieval gives grounded answers with citations.
• Generation of model text: LLMs write textual SysML v2; the parser and API validate syntax and semantics, and invalid output is fed back for repair (generate-validate loop).
• Tool access: agents call RM/MBSE tools through APIs or MCP servers [5]; write access limited to "proposal" status.
• Human-in-the-loop: every change is a proposal; approval, baselining and verification sign-off stay with named engineers.

Data preparation

Typical sources are requirement specifications in Word/PDF/ReqIF, customer and standards documents, the RM tool (DOORS, Polarion, Jama), SysML or Capella models, and review comments in mail or tickets. In an SMB much of this lives in file shares and old project folders, partly as scans or tables with inconsistent IDs.

Typical gaps: duplicated and unversioned document copies, requirements without unique IDs or trace links, mixed languages and terminology, scanned customer specifications, no marked "approved baseline", and open access to confidential projects.

Preparation steps: - Inventory and rank sources per project; use only approved baselines (see PREP-001, PREP-002). - Convert scans and legacy formats with OCR/parsing, keeping clause IDs and tables (PREP-006, PREP-007, DOC-014). - Restructure folders and add metadata such as project, version, status (PREP-009, PREP-010). - Collect a glossary and abbreviations (PREP-015) and a gold set of well-written requirements (PREP-016). - Check access rights per project before indexing (PREP-023).

Tools: Docling or similar parsers, ReqIF export, a vector index. Expect roughly 40-50 % of the total effort to go into data preparation; the model part is the smaller share. Check readiness with GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path B, because the value comes from custom checks against your own style guide and tool landscape, and vendor AI modules are still early; use Path A add-ons instead if you already run Polarion, Jama or Codebeamer and the module fits.
• Enterprise: Path C, because requirements and system models are trade secrets (often export-controlled) and a shared internal LLM platform serves many engineering use cases.
• Developer: Path B, because ReqIF/REST export, an agent framework and the SysML v2 API make a validated proposal pipeline quick to build.

Path A — Buy (off-the-shelf)

• RM/ALM platforms with AI features: IBM Engineering Requirements Management DOORS Next, Siemens Polarion and Teamcenter, Jama Connect (requirements-quality advisor), Codebeamer (PTC), Visure Requirements (ES, EU), Innoslate (SPEC Innovations). Feature sets change quickly; verify current AI modules and data-use terms.
• MBSE tools: Dassault CATIA Magic / Cameo (SysML v2 support), Ansys SCADE and Systems tools, Eclipse Capella (open source, originated at Thales, FR) with the Obeo ecosystem (FR), Sparx Enterprise Architect, PTC Windchill Modeler.
• Choose A when: you already run one of these tools; vendor assistants sit closest to the data and permissions model.

Path B — Build on cloud APIs

• Models: frontier reasoning LLMs with long context and structured outputs (Claude, GPT, Gemini; Mistral as EU provider), in EU regions (e.g. Azure OpenAI EU, Google Vertex EU, AWS Bedrock Frankfurt).
• Stack: ReqIF/REST export from the RM tool, document parsing (Docling, Mistral OCR), hybrid index (OpenSearch, pgvector), orchestration with an agent framework, SysML v2 API (Systems-Modeling pilot implementation) for validation, results written back as proposals [4].
• Choose B when: you need custom checks (company style guide, domain ontology) across tools.

Path C — Self-host (open source)

• Models: open-weight reasoning/code LLMs (Qwen3 / Qwen3-Coder, Mistral Large / Devstral, gpt-oss, Llama family) via vLLM; embeddings such as bge-m3 or Qwen3-Embedding.
• Tools: Eclipse Capella [6], SysML v2 pilot implementation and Jupyter kernel [4], Syside/other SysML v2 parsers, Neo4j or Apache AGE for the model graph, Docling for parsing.
• Hardware: HW3 (one 48-141 GB GPU) for a ~30-120B model with long context; HW4 for several concurrent teams. Required for classified, export-controlled or trade-secret projects.

Path D — Custom training

Fine-tune a mid-size model on the organisation's approved requirement corpus, style guide and accepted/rejected review comments (thousands of items) to improve template compliance and domain vocabulary, or to train a classifier for trace-link prediction. Usually worthwhile only after RAG and validators plateau; curate data (approved baselines only) and keep project confidentiality.

State of the art (2026)

• Textual SysML v2 and its API are the key shift: LLM generation can be validated by a parser instead of by eye, and tool vendors are adding assistants on top. Research on LLM-generated SysML and requirement-quality checking shows promising but uneven results; syntactic validity is achievable with repair loops, semantic correctness (right architecture, right allocation) is not.
• Requirement quality checking is the most mature task: rule engines plus LLM explanations match INCOSE/EARS rules well; extraction from long tenders works with human review.
• Trace-link recovery with embeddings and rerankers is useful for suggestions; precision degrades across abstraction levels, so suggestions need confirmation.
• Limits and failure modes: hallucinated requirements or invented numeric values; silent loss of "shall/should" distinctions; plausible but wrong allocations; ignoring cross-document conflicts; prompt injection through supplier documents; over-trust ("automation bias") in reviews. LLMs do not replace verification, safety analysis or system-level trade-offs.

Shared resources & combinations

• Same stack (llm-reasoning + vector-db + knowledge-graph + ocr-docparse): DOC-015 tender analysis, CODE-015 requirements from stakeholder input, DOC-013 engineering drawings, KNOW-020 part reuse, LANG-022 technical documentation.
• Downstream: SCI-025 FMEA/8D assistant (hazard and failure links), CODE-020 safety-critical software (requirement-to-code-to-test traceability), SCI-024 CAD copilot (geometry from requirements).
• A single self-hosted LLM server (HW3) plus one hybrid index can serve all of these.

Effort, cost & KPIs

• Path A: weeks for activation plus change management; licences per seat/module.
• Path B: 3-6 months for a production assistant with RM-tool integration and evaluation set.
• Path C: 4-9 months incl. GPU operations, security hardening and evaluation.
• Cost drivers: integration with legacy RM tools, curation of an evaluation set, long-context inference, review effort.
• KPIs: share of AI proposals accepted/edited, requirement-defect density at review, review cycle time, trace coverage (requirement to design to test), change-impact analysis time, defects escaping to later phases, hallucination rate on a gold set.

People & change

Involve management and the department lead first: they set scope, budget and the rule that AI output is only ever a proposal. Bring in IT and the data owners of the RM tool and project shares early for exports, accounts and access rights; IT security must review the handling of confidential or export-controlled content before any cloud path (GUIDE-013).

Works council: usually depends. The assistant itself does not evaluate people, but approval logs and per-user usage data make the system objectively suited to monitor behaviour, so §87(1) no. 6 BetrVG often applies; in any case the council must be informed in good time under §90(1) no. 3 and may call in an expert under §80(3). Start the talks before the pilot (GUIDE-004).

DPO: requirement documents contain names of authors and reviewers, so involve the DPO for AVV and a short DPIA screening (GUIDE-005).

AI literacy: support engineers with a short training on limits, hallucinated clauses and verification (GUIDE-006). Choose a pilot group of 3-5 engineers on one project and let them be the champions (GUIDE-008, GUIDE-009). Typical concerns are deskilling and liability; address them by keeping approval, baselining and sign-off with named engineers.

Risks, regulation & compliance

• EU AI Act: the assistant itself is normally minimal risk (an internal productivity tool, no Annex III use); AI literacy duty (Art. 4) applies [7]. The product being engineered may be high-risk (e.g. safety component, medical device, Annex I machinery) and requires its own conformity assessment; the assistant must not hide AI-generated content from that process. Defence-only systems fall outside the Act's scope, dual-use may not. No Art. 5 practice is involved.
• Functional safety and standards: ISO 26262, IEC 61508, IEC 62304, DO-178C/DO-330 expect qualified tools or independent verification; treat LLM output as untrusted and keep review and verification evidence independent of the tool.
• GDPR: mostly no personal data; names of authors/reviewers and supplier contacts in documents count; use DPA and EU hosting where cloud APIs are used.
• IP and export control: specifications are trade secrets and may be export-controlled (dual-use, ITAR/EAR-type content); prefer Path C or contractually zero-retention EU hosting.
• Security: prompt injection via documents; limit agents to read access plus proposal writes.
• Mitigations: citation of sources per suggestion, validators, audit log, versioned baselines, evaluation set re-run on each model change.

Getting started

1. Pick one subsystem and export its requirements (ReqIF/CSV) plus the linked model and tests.
2. Run quality checks (rules + LLM) on 200-500 existing requirements; compare against past review findings.
3. Build a gold set of 50-100 reviewed requirements and trace links to benchmark models and prompts.
4. Pilot "proposal-only" write-back in the RM tool; log accept/edit/reject per suggestion.
5. If using SysML v2, add the generate-validate loop against the parser/API before scaling.

Sources

1. INCOSE — Guide to Writing Requirements — https://www.incose.org/products-and-publications/se-guide-to-writing-requirements
2. Alistair Mavin et al. — EARS (Easy Approach to Requirements Syntax) — https://alistairmavin.com/ears/
3. OMG — Systems Modeling Language (SysML) v2 specification — https://www.omg.org/spec/SysML/2.0/
4. Systems Modeling — SysML v2 Release (pilot implementation, API services, Jupyter) — https://github.com/Systems-Modeling/SysML-v2-Release
5. Model Context Protocol — https://modelcontextprotocol.io
6. Eclipse Capella — Open source MBSE solution (Arcadia method) — https://eclipse.dev/capella/
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. IBM — Engineering Requirements Management DOORS Next — https://www.ibm.com/products/doors-next
9. Siemens — Polarion ALM — https://plm.sw.siemens.com/en-US/polarion/