AI Requirements Management for Regulated Industries: Combining Anthropic Claude’s AI-Native SDLC with IBM Engineering Lifecycle Management

By Bartosz Chrabski, Head of Engineering at SmarterProcess, IBM Champion, and Joe Fitzpatrick, VP Sales at Alidade Technology

October 20, 2026 · 16 min read

1. The bottleneck in regulated teams is evidence

Anthropic’s playbook on the AI-native software development lifecycle, published in August 2026, makes a claim that is hard to argue with: AI agents now write code faster than any team can plan it, review it or release it, so the time goes into the process around the code. For the teams I work with, the bottleneck sits somewhere else.

I have spent most of my career deploying IBM’s engineering tools at companies that build cars, aircraft, defense systems and medical devices. I agreed with almost everything in the playbook. The slow part it describes is just not the one my customers feel most.

For a team working under ISO 26262 or DO-178C, typing code is rarely the slow part, and neither is reviewing it. The slow part is proving that every requirement was analyzed, implemented, verified and approved by the right person, in the right baseline, for the right product variant. An agent that writes code ten times faster does not help if the traceability matrix still takes three weeks to assemble before an audit.

So my question is practical. If you already run IBM Engineering Lifecycle Management, how do you adopt an AI-native SDLC without losing the evidence your assessors depend on? My answer: let the AI work at AI speed in the repository, keep IBM Engineering Lifecycle Management as the system of record, and connect the two so that traceability comes out of the work itself instead of a separate project before every audit.

2. The AI-native SDLC in one page

If you have read the playbook, skip to the last paragraph of this section.

Anthropic estimates forty minutes of reading for the full playbook. Its core idea fits in one sentence: each stage of the lifecycle ends by committing a versioned artifact that the next stage reads, so the lifecycle becomes a loop instead of a chain of handoffs.

For regulated teams, the most useful part is how the playbook handles control. Skills tell Anthropic Claude how to behave, but the playbook is clear that a skill is advisory. Rules that must always hold go into hooks, which can block an action before it happens, and into managed settings that individual engineers cannot override. The agent that wrote a change cannot approve it: in the playbook’s words, the agent may act up to the production gate and cannot pass it. Version control then records who asked for what, what the agent produced and who approved it.

One sentence in the playbook is easy to miss. It admits that systems such as Jira, ServiceNow or change boards are hard to replace because auditors and regulators already accept them, and it advises keeping the system of record where auditors expect it and linking it to the markdown artifacts. For an IBM Engineering Lifecycle Management customer, that system of record is already in place.

3. Where the playbook stops in regulated engineering

A repository full of markdown files and commits is a good audit trail for software. A safety case needs more. An assessor in automotive, aerospace or medical devices will typically ask for five things that a Git repository does not give you on its own.

• A release is a consistent set of stakeholder requirements, system requirements, architecture models, software requirements, tests and results, frozen together and reproducible years later. A commit is one piece of it.
• Hazards, safety goals and system requirements belong to systems and safety engineers, and many of them trace to hardware rather than code. Those people do not work in Git, and they should not have to.
• Most of my customers ship product lines. The same requirement may apply to three variants and be modified for a fourth. Branches handle code variants well and requirement reuse across product lines badly.
• Many quality systems require recorded reviews with named approvers, and medical and some defense programs require electronic signatures.
• Standards ask what each tool in your process does and what happens if it makes a mistake. “We use an AI agent” needs an answer here (section 8).

IBM Engineering Lifecycle Management was built for these jobs. IBM Engineering DOORS Next holds requirements with history, attributes, reviews and links. IBM Engineering Workflow Management (EWM) manages work items and change, IBM Engineering Test Management (ETM) manages test plans, cases and results, and IBM Engineering Rhapsody with IBM Engineering Rhapsody Model Manager (RMM) holds SysML and UML models. IBM Engineering Global Configuration Management ties versions of all of them into one baseline. The links between them use OSLC, an open standard.

4. Mapping Anthropic Claude’s artifacts to IBM Engineering Lifecycle Management

The first design decision is where each kind of information lives. My recommendation is a split rule:

Requirements an assessor will trace live in IBM Engineering DOORS Next. Implementation detail lives in the repository and links back to IBM Engineering Lifecycle Management.

That puts stakeholder, system, safety and software requirements in DOORS Next, where they are baselined and reviewed. The spec.md and plan.md files that Anthropic Claude writes for a specific change are working documents in the repository. They reference the DOORS Next requirements they implement and are never the only place a requirement exists.

With that rule in place, the playbook stages map onto IBM Engineering Lifecycle Management like this:

Our guide to the requirements traceability matrix shows what a complete chain from requirement to test looks like in DOORS Next.

5. Architecture: Anthropic Claude Code, SmarterMCP and IBM Engineering Lifecycle Management

For any of this to work, Anthropic Claude has to read from and write to IBM Engineering Lifecycle Management under control. The Model Context Protocol (MCP) is the standard way to give Anthropic Claude access to an external system, and at SmarterProcess we built SmarterMCP for IBM Engineering Lifecycle Management, an MCP server that exposes IBM Engineering DOORS Next, IBM Engineering Workflow Management (EWM), IBM Engineering Test Management (ETM), IBM Engineering Rhapsody, IBM Engineering Rhapsody Model Manager (RMM) and IBM Engineering Global Configuration Management to Anthropic Claude.

The architecture has four layers:

1. Anthropic Claude Code, running on the developer’s machine or in CI, with the organization’s CLAUDE.md, skills, hooks and managed settings.
2. SmarterMCP, which turns Anthropic Claude’s requests into calls to those applications over OSLC and their REST interfaces. It runs where the customer needs it: on premises next to the IBM Engineering Lifecycle Management servers, in a private cloud, or in a container.
3. IBM Engineering Lifecycle Management, the system of record, with its existing projects, permissions, configurations and process rules.
4. The repository and CI, which hold code, spec.md, plan.md, tests and pull requests.

Auditor mode: read only

SmarterMCP can run in a mode where Anthropic Claude reads requirements, links, work items, test results and baselines but cannot change anything. This mode earns its keep well beyond development. A quality engineer or an assessor can ask which safety requirements in a baseline have no passing test, or which requirements changed since the last release, and get the answer from live data with no risk of modifying it.

Write mode, with rules on top

In write mode, Anthropic Claude can create links, update work items and record test results. It acts with the permissions of the IBM Engineering Lifecycle Management user it connects as, so the platform’s own access control and process rules still apply. Anthropic Claude Code hooks add deterministic rules on top of that. A typical hook blocks any attempt to modify a requirement in a frozen baseline, or to write to a module that matters for safety, whatever the agent was asked to do.

Not tied to one AI vendor

SmarterMCP speaks the open Model Context Protocol, so Anthropic Claude is not the only assistant that can use it. GitHub Copilot, OpenAI Codex, Google Gemini CLI and Cursor can all connect to MCP servers, and the split rule, the auditor mode and the permissions in IBM Engineering Lifecycle Management work the same way with any of them. What changes from tool to tool is the guardrail layer. Hooks and managed settings are features of Anthropic Claude Code, so with another assistant you need its equivalent before you allow writes. This article uses Anthropic Claude because the playbook it builds on is Anthropic’s.

6. One change, end to end

A single change moves through the combined process like this. The details differ by industry (section 7); the shape stays the same.

1. Requirement. A system requirement in IBM Engineering DOORS Next is approved and included in the current stream: “The braking controller shall log every activation of the emergency brake with timestamp and vehicle speed.” It traces up to a stakeholder requirement and, through the safety analysis, to a safety goal.
2. Work item. A work item is created in IBM Engineering Workflow Management (EWM) and linked to the requirement. Anthropic Claude can do this through SmarterMCP, or the team lead does it as usual.
3. Specification. The engineer starts Anthropic Claude Code. Anthropic Claude reads the requirement, its parent and its existing links through SmarterMCP and drafts a spec.md for the change. Organization skills check the draft against coding and safety guidelines. The engineer reviews it and commits it with the DOORS Next requirement ID in the header.
4. Plan and code. In plan mode, Anthropic Claude proposes a plan.md. The engineer challenges it, then Anthropic Claude writes the code and unit tests. Hooks block edits to protected paths, and to test files while Anthropic Claude is fixing a failure.
5. Commit and link. Commits and the pull request reference the EWM work item, so EWM shows which code changes implement the work item and, through it, the requirement.
6. Verification. CI runs the tests and records the results in IBM Engineering Test Management (ETM) against test cases linked to the requirement. Coverage of the requirement is now visible in IBM Engineering Lifecycle Management.
7. Review. An AI review pass checks the pull request against REVIEW.md, spec.md and the linked requirement. A human reviewer who did not write the change approves it.
8. Baseline. At the release milestone, the IBM Engineering Lifecycle Management administrator creates a global baseline in IBM Engineering Global Configuration Management with the requirements, the work items, the test results and a reference to the repository tag.

Nobody built a traceability matrix by hand.

7. Three industries, three sets of rules

The architecture stays the same in every regulated domain. What changes is what the standard asks for, and where AI work ends and human accountability begins.

Automotive: ISO 26262 and Automotive SPICE

Automotive teams usually work under two standards at once: ISO 26262 for functional safety and Automotive SPICE (ASPICE) for process capability. ASPICE assessors look closely at the software engineering processes from requirements analysis to verification (SWE.1 to SWE.6), and at bidirectional traceability and consistency between them. ISO 26262 adds safety requirements classified by ASIL, with stricter methods at higher ASILs.

Consistency is where AI work gets automotive teams into trouble. ASPICE asks for it explicitly, and links alone do not prove it. A spec.md that drifts from its IBM Engineering DOORS Next requirement is a finding waiting to happen, so the rule is: if the specification needs to say something the requirement does not, change the requirement in DOORS Next first.

Within that rule, Anthropic Claude drafts software requirements from system requirements for engineers to refine, proposes spec.md and plan.md for each change, writes unit tests, and checks requirements, code and tests against each other before review. In auditor mode it helps prepare for an ASPICE assessment by finding requirements without tests, tests without requirements, and links that point to outdated versions. The software requirements stay in IBM Engineering Lifecycle Management with their ASIL, verification method and status, together with their traceability to system and safety requirements, the test specifications and results, and the baselines for each release and variant. People approve every safety requirement, decide on ASIL decomposition, and review changes to ASIL C and D components independently.

Aerospace and defense: DO-178C

DO-178C assigns each software component a Design Assurance Level from A (catastrophic failure condition) to E. It separates high-level requirements (HLR) from low-level requirements (LLR) and requires traceability from system requirements through HLR and LLR to source code and tests. At the higher levels it also asks for independence in verification and for structural coverage analysis, up to MC/DC at Level A.

Independence decides how far AI can go here. At Levels A and B, certain verification activities must be performed by someone other than the author. The agent that wrote the code cannot be that someone, and in my view neither can another AI agent without qualification (section 8). People review the code and tests Anthropic Claude wrote, and that review is recorded.

Below that line there is plenty for Anthropic Claude to do. It helps engineers derive LLRs and check them against HLRs, writes code and requirements-based tests, reads structural coverage reports and proposes tests where coverage is missing, and checks that every source file traces to an LLR. In auditor mode it summarizes traceability and open problem reports from IBM Engineering Lifecycle Management ahead of each Stage of Involvement with the certification authority. The HLRs and LLRs with their trace links, the verification cases, procedures and results, the problem reports and the configuration index for each software baseline all stay in IBM Engineering Lifecycle Management.

Watch for derived requirements. When Anthropic Claude introduces behavior that does not trace to an HLR, that behavior has to become a derived requirement in IBM Engineering DOORS Next and go to the safety assessment. A code comment is not enough.

Medical devices: IEC 62304

AI agents add libraries readily. In a Class B or C medical device, every new dependency is a piece of software of unknown provenance (SOUP) that needs requirements, a risk assessment and a version record. A hook that blocks new dependencies until a SOUP entry exists is a cheap safeguard.

IEC 62304 classifies medical device software as Class A, B or C by the harm it can contribute to, and the rigor required grows with the class. It requires traceability between system requirements, software requirements, software system tests and the risk control measures from the ISO 14971 risk management process.

Anthropic Claude drafts software requirements and test cases, checks that every risk control measure in IBM Engineering DOORS Next is implemented and verified, and keeps the SOUP list current when dependencies change. In auditor mode it helps assemble evidence for the design history file and answers questions during internal audits. IBM Engineering Lifecycle Management keeps the software requirements, the risk control measures and their links to hazards, the verification records, the anomaly reports, and the electronically signed reviews that many medical quality systems require. Software safety classification, acceptance of residual risk, and approval of each requirement and verification record in the design history file stay with people.

8. Will an auditor accept work written by AI?

This is the question I hear most often. The standards ask whether the output was verified, and whether a tool that replaces a verification activity can be trusted to do so. Authorship does not come into it.

DO-178C and ISO 26262 both have explicit rules for that second question. Under DO-178C, a tool needs qualification if it eliminates, reduces or automates a DO-178C process and its output is not verified. DO-330 then sets a tool qualification level from TQL-1 to TQL-5, based on the software level and on whether the tool could insert an error or only fail to detect one. ISO 26262 Part 8 gives each tool a tool confidence level from TCL1 to TCL3, based on its possible impact on safety and on the probability that an error would be detected. A higher TCL means qualification measures are needed.

Today no AI model of this kind is qualified under DO-330 or classified at a low TCL in a way an assessor would accept by default, and I would not plan a program around that changing soon. My recommendation:

Treat Anthropic Claude as an unqualified tool whose every output is verified. The compliance evidence is the human review and the verification recorded in IBM Engineering Lifecycle Management, not the AI’s work.

That has four consequences:

• Code written by AI goes through the same reviews, tests and coverage analysis as any other code.
• AI review is an extra pass that finds problems earlier. It earns no verification credit and does not replace a required human or independent review.
• Every requirement, test result and approval that forms evidence is stored in IBM Engineering Lifecycle Management, linked and baselined.
• Your tool classification or qualification documentation lists Anthropic Claude, SmarterMCP and the hooks you rely on, with each one’s role and how its output is checked.

The cost of this position is that you pay for review twice, once by the AI and once by a person. While no AI model is qualified, I think that is the right trade: the AI pass finds problems before a person spends time on them.

9. What to measure

The playbook suggests leading and lagging indicators for each stage, including DORA metrics such as lead time and change failure rate. For regulated teams I would add measures that show whether speed is costing you evidence:

10. How to start with AI requirements management

Do not try to change the whole lifecycle at once. The playbook recommends starting with one stage and one artifact type, and that advice fits regulated programs even better.

1. Pick one team and one component, preferably one with a lower safety classification.
2. Connect Anthropic Claude to IBM Engineering Lifecycle Management in auditor mode first. Engineers and quality staff can ask about requirements, coverage and baselines, which builds trust and shows data quality problems early.
3. Agree on the split rule for what lives in IBM Engineering DOORS Next and what lives in the repository.
4. Turn on write access for links and test results, with hooks that protect baselined content and anything relevant to safety.
5. Write down the tool classification for Anthropic Claude and SmarterMCP before your next assessment, not after.
6. Track the measures above, and move to the next team when throughput goes up and those numbers hold.

If you run IBM Engineering Lifecycle Management and want to try this, book a free consultation (30 minutes). We will look at your setup, the standards you work under, and where an AI-native SDLC would help first. Teams that want to go further can follow it with our AI-native SDLC for IBM Engineering Lifecycle Management teams workshop, a structured assessment that ends with a pilot plan, a split rule for your requirements and a draft tool classification.

Contact

• Europe and Asia Pacific: Bartosz Chrabski, SmarterProcess, bartosz.chrabski@smarterprocess.pl, +48 666 74 71 74
• Americas: Joe Fitzpatrick, Alidade Technology, JMFITZ@AlidadeTech.com, +1 610-247-9595

Further reading: Requirements management and traceability with IBM Engineering DOORS Next · Requirements traceability matrix: what it is and how to build one · MBSE with IBM Engineering Rhapsody and SysML · Anthropic, The AI-native SDLC playbook, August 2026.