Tag Archive for: Requirements & Requirements Management
Tag Archive for: Requirements & Requirements Management
Jama Connect has once again been named a Leader in G2’s Summer 2026 Grid® Report for Requirements Management Software. This recognition, based on data gathered by April 28, 2026, comes directly from the engineering teams who use Jama Connect to build complex, regulated products every day.
Below, you’ll see exactly what we earned in the report, what our customers said, and why Jama Connect continues to lead the category.
What Jama Connect Earned in the G2 Summer 2026 Report
G2 rankings reflect verified user reviews and real market performance. Jama Connect was recognized across the board:
Overall Leader in the G2 Grid® for Requirements Management
Enterprise Leader for strong performance in large organizations
Mid-Market Leader for results among mid-sized teams
Small Business Leader for small business requirements management
EMEA Leader and Europe Leader across regional grids
Momentum Leader, ranked in the top 25% of products for growth and innovation
Best Relationship for customer success and commitment
What Jama Connect Customers Say
The scores tell the story. Jama Connect earned a customer satisfaction score of 95, and the user feedback backs it up:
95% rated Jama Connect 4 or 5 stars.
86% said they would recommend us.
86% believe Jama Connect is headed in the right direction.
Recognition like this is earned through consistent performance. It signals that teams managing safety-critical requirements, regulatory compliance, and complex development cycles trust Jama Connect to deliver.
Multidisciplinary engineering teams face a constant tension: move faster without cutting corners on quality or compliance. Jama Connect is purpose-built to resolve that tension. Here’s what sets it apart.
Live Traceability™
Jama Connect maintains end-to-end traceability across the development lifecycle. Teams navigate upstream and downstream relationships with ease, manage rigorous change control, and prove compliance without the manual burden of chasing documentation across siloed tools.
AI-Driven Development
Jama Connect now powers AI-Driven Development for regulated teams through:
Jama Connect Advisor™: Natural language processing improves requirements quality by applying INCOSE rules and EARS notation, reducing the ambiguity and contradictions that drive 70%-80% of rework costs.
Jama Connect MCP™ Server: Jama Connect is the first engineering management platform to deliver an MCP Server, advancing AI-Driven Development while keeping AI outputs auditable and compliant. It improves product velocity, inference quality, and token efficiency.
Purpose-Built for Regulated, Multidisciplinary Teams
Jama Connect helps teams in medical devices, aerospace and defense, automotive, semiconductor, and more comply with industry-specific standards without slowing development. AI-generated requirements, test cases, and traceability adhere to the standards each industry demands.
The AI-Native Engineering Management Platform
This recognition reinforces our direction. Jama Connect is now an AI-native engineering management platform built to increase product velocity for regulated, multidisciplinary teams.
The premise is straightforward: siloed teams, tools, and data prevent companies from realizing the velocity gains AI promises. Jama Connect acts as the product context layer that connects them, maximizing LLM inference quality, enabling parallel engineering across disciplines, automating with CI/CD pipelines, and maintaining AI governance and standards compliance. The goal stays the same: let engineers focus on engineering, not on tooling and paperwork.
The G2 Summer 2026 results confirm what our customers already know: Jama Connect leads requirements management for teams that need clarity, traceability, and confidence across the development lifecycle.
Ready to dig deeper? Download the G2 Summer 2026 Grid® Report to see the full results, or request a personalized demo and we’ll show you how Jama Connect helps regulated, multidisciplinary teams move faster without sacrificing quality or compliance.
Imagine a state agency deploys an AI tool to help draft procurement requirements. The tool is fast, the outputs look good, and program staff start using it across multiple projects.
Six months later, the inspector general requests documentation showing how a specific contract requirement was developed, who approved it, and how it connected to the original policy directive.
No one can produce that record.
The AI tool did exactly what it was supposed to do, but the governance structure around it didn’t.
This scenario plays out in variations across state government every day. AI adoption is accelerating, but the frameworks needed to make that adoption defensible, including under legislative oversight, audit scrutiny, procurement challenges, and public records requests, haven’t kept pace.
This article outlines concrete challenges of governing AI at scale in government settings, explaining why they’re especially difficult for state agencies, and offers practical guidance on where to focus first.
The Top Challenges of Governing AI at Scale for State Agencies
1. Unclear Ownership Across Teams
When an AI tool gets deployed, multiple teams often think someone else owns it:
The business unit that requested it assumes IT manages it.
IT assumes the vendor is accountable.
The vendor assumes the agency defined the acceptable use.
This distributed confusion isn’t unique to government, but it’s more consequential there. In the private sector, a gap in AI ownership creates operational risk.
In state government, it can mean a program operates without accountable review, a use case expands beyond what was originally authorized, or no one flags that an AI output influenced a high-stakes decision without oversight.
Effective AI governance requires clearly defined ownership at every stage:
Who approved the use case
Who monitors ongoing use
Who has authority to expand or restrict it
Who is responsible if something goes wrong
Here’s what this looks like in practice. A state agency might have a program manager, an IT lead, a compliance officer, and a vendor all involved in an AI implementation.
Without explicitly assigning who owns governance decisions, each one defers to the others. The result is no one does.
2. Weak Requirements Quality Before AI Is Applied
This is one of the most underappreciated AI governance challenges, particularly in government programs: AI tools amplify ambiguous input.
When a requirement is incomplete, untestable, or vague, running it through an AI workflow produces an output that is harder to trace back to what was authorized.
The speed of AI makes this worse, because teams can move far down a development path before anyone notices the foundational requirement was flawed.
Strong governance requires that requirements meet basic quality standards before AI touches them:
Complete: They define what they need to define, without gaps
Testable: Outcomes can be verified against them
Unambiguous: There is one clear interpretation
Appropriately scoped: They specify what’s included and what isn’t
Catching quality issues at the point of authoring is far less costly than catching them during an audit, a procurement challenge, or a legislative review.
3. Limited Traceability Between Outputs and Approved Requirements
Requirements traceability is a basic accountability standard in government programs. It’s also one of the first things to break down when AI is introduced without governance structure.
AI tools produce outputs quickly. When those outputs aren’t linked to the requirements that authorized them, the agency has no reliable record of:
Where a decision came from.
What authorized it.
Whether it stayed within approved scope.
This is a governance architecture problem. Traceability needs to be built into the workflow from the beginning. It is something to be not assembled after the fact when an audit request arrives.
When traceability is part of normal work, agencies get a clear, continuous record.
They know how requirements evolved, what decisions were made, and how every deliverable connects to an approved specification.
4. Invisible Downstream Impacts When Requirements Change
Requirements change, that’s normal in any government program.
What’s not normal, but increasingly common with AI-assisted workflows, is that downstream work doesn’t automatically reflect those changes, and no one knows it.
When a requirement is updated in a well-governed system, there’s a clear signal about what work is now out of alignment.
When that structure doesn’t exist, teams continue building on a requirement that’s no longer current. They may deliver a product that doesn’t match what was authorized, without knowing it until a review surfaces the gap.
This is particularly at risk in AI workflows because outputs are produced faster and in higher volume. A single upstream requirement change can affect a large body of downstream work before anyone catches it.
Governance needs to include change visibility, a mechanism that surfaces what’s affected when a requirement changes, so program managers can make informed decisions rather than discover problems at the worst possible moment.
5. After-the-Fact Documentation
Most government programs still build compliance documentation at the end of a project cycle. This was always imperfect, but with AI-assisted work, it becomes untenable. AI tools can generate large volumes of work in a short time. Reconstructing the decision trail for all of it is time-consuming, often incomplete, and frequently inaccurate.
The solution is to shift documentation from a closing task to a byproduct of normal work. When links between requirements and outputs are created at the time work is done, and every action connected to a requirement is logged in a version-controlled record, agencies don’t face a documentation gap. They have an accurate, continuous audit trail.
6. Controls That Don’t Match the Risk Level of Each Use Case
Not every AI use case carries the same risk. An AI tool used internally to summarize meeting notes is very different from one used to help evaluate procurement bids, score program applications, or develop regulatory guidance.
One of the most common AI governance challenges is applying the same governance requirements to every use case, or applying no requirements at all. Both are failures.
When controls are too light for high-stakes uses, the agency is exposed. When controls are too heavy for low-stakes uses, teams work around them, and the governance process loses credibility.
Effective governance applies controls that match each use case’s actual risk profile, factoring in:
The stakes of the outputs (who is affected and how).
Whether AI-generated content requires human review before use.
What data the system accesses and how it’s protected.
The regulatory and oversight environment for that program area.
Matching controls to use-case risk is harder than applying a blanket policy, but it produces governance that people follow.
7. Low Visibility into How AI Is Being Used
This challenge tends to grow as AI usage expands. Tools proliferate, with some approved and others adopted informally. Without a clear view of where AI is being used, it’s nearly impossible to identify higher-risk activity. This visibility gap creates a compounding problem: the more AI is used, the harder it becomes to govern.
A practical approach is maintaining an active inventory, covering approved systems, AI features embedded in existing tools, and known informal uses. This becomes the foundation for prioritizing governance resources and identifying where controls need to be strengthened.
Why These AI Governance Challenges Are Especially Critical for State Agencies
The challenges of governing AI at scale affect all types of organizations. But state government agencies face a specific combination of pressures that makes these challenges more acute.
Non-Negotiable Accountability Standards
Legislative oversight, inspector general reviews, procurement audits, and public records requests all require a clear, traceable record of what was decided, why, and how it connected to authorized requirements.
In private organizations, gaps in that record can be managed internally. In government, they become public problems.
Explainability Isn’t Optional
When an AI-assisted decision affects a contract award, a program eligibility determination, or a regulatory outcome, agencies need to explain how that decision was made.
“The AI tool recommended it” is not an acceptable answer in any oversight context.
The governance structure needs to produce an explanation that survives scrutiny.
Requirements Documentation Carries Legal Weight
In government programs, what was authorized matters as much as what was delivered. Requirements serve the purpose of internal planning. They are also the basis for contract terms, compliance reviews, and procurement challenges.
Weak requirements quality and poor traceability open the door to operational risk and legal exposure.
Constrained Resources
State agencies can’t always match the governance infrastructure of large federal agencies or well-resourced private companies.
That makes it even more important to build governance into workflows efficiently, rather than layering on documentation requirements after the fact.
What State Agencies Need to Prioritize Before Scaling AI
The good news is that you don’t need to stop everything you’re doing. However, you do need to set the right foundation before adoption expands.
Before scaling AI use across programs, agencies need to focus on these priorities.
Establish Quality-Reviewed Requirements as the Starting Point
AI should only be applied to work that is well-defined, testable, and unambiguous. Requirements that fail basic quality checks should be resolved before AI enters the workflow.
Assign Clear Ownership for Every AI Use Case
Define who is accountable for governance decisions, who monitors ongoing use, and who has authority to approve expansions or changes. Accountability can’t be assumed; it needs to be explicit.
Build Traceability Into Workflows From the Beginning
Links between requirements and outputs should be created as work is done, not reconstructed afterward. Every deliverable should trace back to an approved specification.
Create Change Visibility Mechanisms
When requirements change, downstream impacts should be surfaced immediately. Teams shouldn’t discover misalignment at audit time.
Match Controls to Use-Case Risk
Apply more rigorous oversight, including human review, access restrictions, and documentation requirements, where the stakes are highest.
Avoid applying the same controls to everything, which produces friction without proportionate benefit.
Bottom Line: Establish Governance, Then Scale
Speed and accountability aren’t in conflict when governance is designed from the start, not bolted on later.
The agencies that will move fastest with AI are the ones that built the right structure first: clear requirements, explicit ownership, built-in traceability, and controls that match actual risk.
These are what makes AI adoption defensible when oversight comes, and in state government, oversight always comes.
Jama Connect® Can Help
If your agency is working through these challenges, Jama Connect can help you achieve governance and keep AI work defensible from the start.
Jama Connect’s AI capabilities help teams create strong, verifiable requirements with quality analysis and refinement to remove ambiguity. It catches defects at authoring to reduce manual editing cycles and later-stage costs, addressing the root cause of rework.
With immutable audit trails, integrated requirements management, and Live Traceability™ that flags downstream impacts, you’ll reduce late-stage changes and improve product quality.
To see how it fits your mission, explore Jama Connect for the public sector today.
Ready to Enable a Streamlined and Collaborative Digital Workplace
for Government and Public Service Missions? LEARN MORE
TrustRadius is an independent B2B software review platform. The award is determined entirely by verified user reviews.
There are no analyst panels or nominations, just input from the teams who use the product every day.
What the TrustRadius Top Rated Award Signals
The TrustRadius requirements management category is competitive, and earning recognition here requires consistent performance.
It’s a signal that users trust us.
For Jama Connect, that includes managing safety-critical requirements, maintaining regulatory compliance, and accelerating product development across complex, multidisciplinary engineering organizations.
“With Jama Connect, we have the confidence that we can easily show regulators the linkages between each individual item, with full traceability from top to bottom. I can easily click through the whole storyline of how requirements fit into the V-model and what actions we took.”
— Verified Customer, Director of Quality and Regulatory, Medical Device Company
What Jama Connect Is Built to Do
Multidisciplinary engineering teams face a specific challenge: move faster without cutting corners on quality or compliance. Jama Connect is purpose-built for that environment.
Key capabilities include:
AI-Driven Development: Increase velocity for regulated multidisciplinary products with Jama Connect Advisor™ and Jama Connect Model Context Protocol™ (MCP).
Live Traceability™: Maintain rigorous change management with end-to-end traceability. Navigate upstream and downstream relationships with ease across complex product requirements.
Regulatory Compliance Support: Eliminate manual compliance with AI-generated requirements and adhere to industry-specific standards for industries like medical devices, aerospace, automotive, and more.
Collaboration Tools: Keep multidisciplinary teams aligned without adding friction with features like stakeholder commenting, intuitive workflows, and export functionality.
The goal has always been simple: let engineers focus on engineering, not on chasing documentation and tooling.
How Jama Connect Powers AI-Driven Development Today
This recognition reinforces our direction.
Jama Connect recently became the first engineering management platform to deliver an MCP Server, advancing AI-Driven Development for regulated teams.
It improves product velocity, inference quality, and token efficiency while keeping AI outputs auditable and compliant.
If you are evaluating intelligent engineering management solutions or want to see what sets Jama Connect apart in requirements management, request a personalized demo.
Our team will walk you through how Jama Connect helps regulated, multidisciplinary organizations move faster without sacrificing quality or compliance.
A defense program contracts three suppliers before holding its Preliminary Design Review (PDR). Six months into development, each supplier has interpreted the system requirements differently because no authoritative baseline existed when contracts were signed. The integration milestone becomes a discovery event, revealing interface conflicts that trace back to requirements the teams never reconciled. This retroactive traceability problem can spread quickly across the supply chain when requirements are not stabilized before contracts begin.
ISO/IEC/IEEE 15288 exists to prevent these failures. The standard defines lifecycle processes that govern how systems are conceived, developed, produced, operated, and retired. When applied with discipline, it gives programs a shared process structure that spans every tier of the acquirer-supplier hierarchy. When ignored or partially applied, the consequences show up as cost growth, schedule delays, and certification gaps that compound at every stage.
This guide covers what the standard is, how its four process groups fit together, how it compares to adjacent standards, how regulated industries apply it, and the traceability structure that makes 15288 workable at scale.
What Is ISO/IEC/IEEE 15288?
ISO/IEC/IEEE 15288:2023 is the international standard for system lifecycle processes, published jointly by the International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and Institute of Electrical and Electronics Engineers (IEEE). Thecurrent edition appeared in May 2023, supersedes the 2015 version, and carries the full title “Systems and software engineering, System life cycle processes.”
It establishes a common structure of process descriptions for systems created by humans, applicable from conception through disposal. The standard defines its lifecycle processes in four groups. It does not prescribe a specific lifecycle model, development methodology, or technique. Programs can apply the processes iteratively, concurrently, and recursively to both standalone systems and systems of systems.
This lifecycle-model independence is why 15288 applies across waterfall, spiral, and agile approaches. ISO/IEC/IEEE 15288:2023 is often treated as the anchor systems engineering standard, and the International Council on Systems Engineering (INCOSE) Systems Engineering Handbook provides practitioner-level guidance on every process. That role places it at the center of the systems engineeringbody of knowledge.
The Four Process Groups in ISO/IEC/IEEE 15288
The lifecycle processes break into four groups defined in Clause 6. They coversystems engineering work across contract negotiation, development, operation, and disposal. Each group operates at a different team level, and programs tailor their application based on system complexity, mission criticality, and contractual requirements:
Agreement processes: Acquisition and supply activities that define the contractual relationship between buyer and supplier. In defense and aerospace prime/sub structures, these processes govern how requirements flow down, how acceptance criteria are established, and how deliverables are monitored across tiers.
Organizational project-enabling processes: Lifecycle model management, infrastructure, portfolio management, human resources, quality management, and knowledge management. These provide the enterprise scaffolding around individual programs, including the process assets that a program’s systems engineering plan references.
Technical management processes: Project planning, assessment and control, decision management, risk management, configuration management, information management, measurement, and quality assurance. These processes govern how development efforts are managed day-to-day.
Technical processes: The engineering processes from business or mission analysis and user needs definition through architecture, design, implementation, integration, verification, validation, operation, maintenance, and disposal. This is the engineering work itself.
Configuration management connects the other processes. When configuration management is reduced to document control, it fails to bridge disconnected tools and disciplines, and traceability gaps become structural rather than incidental.
How ISO/IEC/IEEE 15288 Compares to Adjacent Standards
ISO/IEC/IEEE 15288 has the greatest breadth but least depth of any systems engineering standard. It works as a skeleton that domain-specific standards fill with technical content. Three adjacent standards interact with it most frequently.
ISO/IEC/IEEE 12207: Software Lifecycle Processes
ISO/IEC/IEEE 12207 defines processes for the software lifecycle. A later revision aligned 12207 more closely with 15288’s process structure, and both now share the same process model, differing primarily in descriptive notes. For software-intensive systems, both standards apply simultaneously. ISO/IEC/IEEE 15288 applies at the system level, and ISO/IEC/IEEE 12207 applies at the software element level.
ISO/IEC/IEEE 29148: Requirements Engineering
ISO/IEC/IEEE 29148 expands therequirements engineering activities that 15288 names but does not detail. It covers the requirements-focused technical processes around business or mission analysis, user needs definition, and system requirements definition. ISO/IEC/IEEE 29148 defines how requirements engineering is performed within a lifecycle, but does not carry tailoring authority. Teams cannot use 29148 to modify process-level obligations established by 15288.
The INCOSE Systems Engineering Handbook
The INCOSESystems Engineering Handbook translates 15288’s normative process definitions into practitioner guidance. Each chapter follows a two-layer structure, with a normative overview consistent with 15288 followed by detailed guidance covering methods and practices. The handbook turns the standard’s tailoring provisions into step-by-step guidance that programs can apply directly to their systems engineering management plans.
ISO/IEC/IEEE 15288 Across Regulated Industries
The standard’s lifecycle process framework appears across industries where systems are complex, long-lived, and subject to regulatory oversight. In each sector, it sits alongside domain-specific safety and software standards rather than replacing them.
Aerospace and Defence
Prime contractors may flow 15288 requirements to suppliers through contract terms. Programs often pair 15288 with MIL-STD-882E for system safety, DO-178C for airborne software certification, and ARP4754A for aircraft-level development assurance.
Defense programs are a significant user community for the standard. ISO/IEC/IEEE 15288 establishes a common framework for describing the lifecycle of engineered systems, and IEEE 15288.1 establishes systems engineering requirements intended to serve as the basis for acquirer-supplier agreements for Department of Defense (DoD) programs.
Automotive
In the automotive sector, ISO/IEC/IEEE 15288 is sometimes discussed as a general systems engineering lifecycle framework for safety and development processes. ISO 26262 defines the safety activities that must occur at each lifecycle phase. ISO/IEC/IEEE 15288 provides the process rigor for how those activities are carried out, structured, and traced through requirements definition and verification. Many automotive teams pair this withAutomotive SPICE (ASPICE), which assesses the maturity of those same lifecycle processes against a defined capability scale.
Medical Devices
For medical device manufacturers building complex products or Software as a Medical Device (SaMD), 15288 can work as an internal systems engineering structure aboveIEC 62304 and ISO 13485. The FDA does not cite 15288 directly, but manufacturers building systems with embedded software, hardware-software interaction, and multi-variant product lines often adopt it.
Nuclear and Energy
The IAEA describes systems engineering as a lifecycle-wide approach for nuclear facilities and points to ISO/IEC/IEEE 15288 as a common process framework. For industrial and energy systems where operation, maintenance, and disposal span decades, 15288’s later-stage processes carry as much weight as the design-phase processes that many programs focus on.
Common Implementation Challenges With ISO/IEC/IEEE 15288
Tailoring the full process set to a specific program without breaking the standard’s intent is an early challenge for teams adopting 15288. Sound tailoring decisions are driven by lifecycle considerations, mission application, team complexity, technical complexity, risk, and technical understanding.
Programs that tailor before completing this characterization are making weakly justified adjustments. Enterprise-scale teams may document broader process coverage than smaller teams, while smaller teams may blur the line between “not applicable” and “not needed.”
Maintainingrequirements traceability across disconnected tools is the second persistent failure mode. When requirements live in one tool, architecture models in another, and verification evidence in a third, no single system can answer whether a given requirement has been verified.
Bidirectional requirements traceability is a commonly expected capability in systems engineering processes, especially in regulated or safety-critical contexts. Programs are expected to align with DoD systems engineering expectations in practice, not just in what their systems engineering management plan documents claim.
Coordinating across distributed teams and suppliers compounds both problems. A single authoritative requirements baseline that multiple teams reference through structured review workflows and Requirements Interchange Format (ReqIF)-based data exchange helps reduce this coordination challenge. Without that shared baseline, interface changes spread without visibility, and configuration management failures cascade from sub-tier suppliers upward.
Best Practices for Applying ISO/IEC/IEEE 15288
A tailored process inventory belongs in place before program execution begins. Teams can build from the full process set and document each inclusion, scaling, or exclusion decision with rationale. That inventory belongs in the systems engineering management plan, baselined in the Request for Proposal (RFP) as an attachment to the Statement of Work (SOW), not after contract award.
Technical processes work best when tied to a formally approvedrequirements baseline managed with practices aligned to ISO/IEC/IEEE 29148, including baseline approval, configuration control, and traceability. Every technical process that consumes requirements, including architecture definition, design, verification, and transition, should trace to that baseline. Verification methods such as analysis, inspection, demonstration, or testing belong with each requirement when it is entered, not after design is underway.
Verification and validation work best when treated as continuous rather than gated phases. The standard permits concurrent, iterative, and recursive application of all processes, including verification and validation. Programs that defer verification to a terminal phase lose the ability to catch requirement conflicts at the integration levels where they are cheapest to resolve.
Verification belongs throughout the integration and development process, not only at the end. Measurement processes belong in place from day one of the lifecycle. Teams should define Measures of Effectiveness during user needs definition, derive Measures of Performance during requirements definition, and establish Technical Performance Measures (TPMs) before architecture trades begin.
These indicators need continuous collection rather than milestone-driven assembly. A program that defines TPMs at PDR cannot use them as leading indicators of architectural risk.
How Jama Connect® Supports ISO/IEC/IEEE 15288
Fragmented traceability and disconnected evidence make the technical and technical management processes defined in ISO/IEC/IEEE 15288 hard to execute. Jama Connect® is a cloud-based requirements management and traceability platform for complex, regulated product development, and it addresses that problem by holding requirements definition, architecture linkage, verification and validation evidence, configuration management, and risk management in one place.
These relationships connect throughLive Traceability™, with Traceability Information Models (TIMs) enforcing expected links between artifact types, so a requirement change flags downstream test cases and risk items as suspect.
For programs operating across distributed teams and suppliers, authoring quality and data exchange become part of the same challenge. The Jama Connect Advisor™ add-on scores requirements against INCOSE rules and Easy Approach to Requirements Syntax (EARS) patterns during authoring.
The Jama Connect Interchange™ add-on supports bidirectional synchronization with tools like Jira and ReqIF-based exchange with supply chain partners, which helps maintain traceability across team boundaries without forcing every participant onto a single tool.
Making 15288 the Operating System for Engineering Work
The programs that get the most from ISO/IEC/IEEE 15288 treat it as the operating system for how engineering work gets done, so compliance becomes the byproduct of a functioning lifecycle rather than an artifact assembled before an audit.
That shift is what separates a standard that lives in a binder from one that shapes daily decisions, and it is increasingly hard to sustain ascost and schedule pressure keep climbing across major acquisition portfolios.
Jama Connect supports this workflow by keeping requirements, verification evidence, and change impact connected throughout the lifecycle, so teams can see coverage and impact without having to reconstruct them before a review. You can see how that works on your own program with afree 30-day trial of Jama Connect.
Frequently Asked Questions About ISO/IEC/IEEE 15288
Is ISO/IEC/IEEE 15288 mandatory?
At the standards level, no. Adoption alone does not make the standard mandatory, and each Program Management Office decides whether and how to apply it. It becomes contractually binding when a Program Management Office cites it in an RFP, SOW, or contract, and defense primes then flow those obligations to suppliers through subcontract terms. Check the solicitation package and subcontract language first, because that language determines whether you are managing 15288 as an internal best practice or as a contractual requirement.
What is the latest version of ISO/IEC/IEEE 15288?
The current edition is ISO/IEC/IEEE 15288:2023, published in May 2023. It supersedes the 2015 edition with improvements to selected technical processes, updates to risk management and configuration management, a new annex on model-based systems engineering, and a change in terminology from “man-made” to “systems created by humans.” Review the tailoring guidance and lifecycle terminology together rather than treating the update as a simple edition-number change.
How does ISO/IEC/IEEE 15288 relate to ISO/IEC/IEEE 12207?
The two standards are aligned so they can be used together, sharing the same overall process architecture and differing mainly in whether the activities target system-level or software-level engineering. When software is the predominant element of interest, 12207 is the standard to lead with. For software-intensive systems, both apply simultaneously, with 15288 governing system-level obligations and 12207 governing software-specific activities. A practical rule follows: use 15288 to manage system responsibilities and 12207 to manage software responsibilities within the same lifecycle structure.
Who uses ISO/IEC/IEEE 15288 in practice?
Defense and aerospace programs are the most visible adopters, often through contract flow-down to suppliers. Automotive teams apply ISO 26262 for functional safety, using 15288 more generally as a lifecycle framework, while medical device and nuclear facility programs adopt it to structure the lifecycle that domain-specific safety standards plug into. Across these settings, the common driver is the need to manage traceability, lifecycle tailoring, and cross-team coordination throughout long, complex development cycles.
Jama Software recently announced that Jama Connect® now delivers a Model Context Protocol (MCP) server. This may appear as a mere technical enhancement, but it represents something more fundamental: a shift in how engineering organizations can operationalize AI within governed, traceable environments.
Requirements and traceability management platforms have long served as repositories for structured engineering knowledge, capturing requirements, decisions, and the relationships between them. Meanwhile, AI tools have largely evolved outside these environments, often operating without access to reliable, governed context. The introduction of MCP begins to bridge this divide, connecting AI capabilities with the structured data.
By enabling AI systems to securely access and operate on structured engineering data, teams can now interact with their source of truth from within AI-enabled environments such as Claude, GitHub Copilot, or Visual Studio. This allows Large Language Models (LLMs) to generate outputs grounded in real project data, improving relevance, reducing ambiguity, and maintaining alignment with traceability and compliance expectations.
From Systems of Traceability to Systems of Insight
The introduction of MCP signals a transition from static data management to dynamic, context-driven insight.
Instead of manually extracting and interpreting information, engineers and stakeholders can query their systems in natural language and receive structured, synthesized outputs. These outputs are not generic, they are grounded in the relationships, baselines, and traceability models that define the system.
This creates a new class of workflows that are AI-assisted, context-aware, and continuously up to date.
Importantly, this is not limited to a single role or activity. The same capability can support a wide range of use cases, from requirements analysis and impact assessment to compliance reporting and design reviews.
To make this more concrete, it is useful to look at one example.
Among the many possible applications, project visibility provides a clear and familiar illustration of the value MCP can unlock.
Project managers and team leads often spend a great amount of time assembling status updates. Information is fragmented across teams, components, and tools. The process typically involves conversations, manual reviews, and iterative follow-ups, followed by the equally time-consuming task of consolidating everything into a coherent narrative, while staying up to date.
With MCP, this process can be fundamentally restructured.
By leveraging the traceability information model, activity streams and content available in their Jama Connect instance, teams can generate structured project evolution summaries on demand. These summaries provide a real-time, system-level view of what has changed, where gaps exist, and which risks or issues require attention.
Instead of chasing updates, project leaders can focus on interpreting and acting on them.
A Practical Illustration: The ThermoCare Example
To explore this pattern, we applied MCP-enabled workflows to a simulated medical device project: ThermoCare, an infrared baby thermometer.
Although simple in concept, ThermoCare reflects the realities of regulated engineering. It includes system and subsystem requirements, architectural decomposition, risk considerations, and full traceability across baselines, aligned with standards such as ISO 13485.
Within this environment, AI-generated summaries were stored directly in Jama Connect in a dedicated project management component (see image below). Both the structure and presentation were configurable, reinforcing that this is a flexible approach rather than a fixed feature.
The generated summaries included:
Executive highlights of key project developments
Milestone timelines with linked evidence
Delivery snapshots of artifacts and progress
Traceability maturity assessments with actionable insights
Recommendations for next steps and areas of focus
Example of project summary report generated via MCP
We also explored time-based queries, such as generating a “last week’s activity” summary. This surfaced the most actively updated artifacts and their contributors, providing immediate insight into project momentum and ownership.
Beyond Project Management: A Reusable Pattern
Project reporting is just one example of a broader pattern and wider range of possibility.
The same MCP-enabled approach can be applied across engineering workflows:
Requirements engineers can analyze completeness, consistency, and change impact
System architects can explore relationships and dependencies across components
Quality and compliance teams can generate audit-ready narratives and traceability evidence
Engineering leaders can gain continuous visibility into program health
In each case, the underlying principle is the same: AI operates on structured, governed context to produce meaningful, role-specific insight.
Early observations by Jama Software development teams using AI suggest meaningful efficiency gains, potentially around 30% at the stage where teams implement AI-assisted workflows, and up to 5x when organizations move toward fully agentic, spec-driven development. These figures come from Jama Software’s AI Adoption Maturity Model (AI-Assisted Software Workflow Playbook Whitepaper), which maps a four-stage progression from initial pilots through cross-disciplinary AI-driven development. However, the more important shift is qualitative.
Teams can identify traceability gaps earlier, assess readiness continuously rather than at milestones, and focus communication on what truly requires attention. Decision-making becomes more proactive, grounded in up-to-date system knowledge rather than retrospective summaries.
Who Should Pay Attention
This evolution is relevant across the engineering organization:
Systems and software engineers managing complex requirement sets
Project managers navigating milestones and delivery pressure
Quality and regulatory teams responsible for compliance and auditability
Any organization operating under structured frameworks where traceability is critical
A Direction for Engineering Workflows
AI in engineering is often discussed in terms of isolated productivity gains. MCP suggests a broader trajectory, one where AI becomes embedded within the core systems that define engineering work.
By connecting AI to structured, traceable context, organizations can move beyond experimentation toward scalable, governed adoption. The larger opportunity lies in rethinking how engineering knowledge is accessed, interpreted, and acted upon, across every role, and throughout the entire lifecycle.
Most importantly, this shift enables engineers and other stakeholders to spend more time on critical thinking, problem solving, and decision making, while leaving to AI the burden of repetitive execution and documentation tasks.
New to Systems Engineering in Medical Device & Life Sciences? Here’s What You Need to Know.
Stepping into systems engineering for the first time, transitioning into a new role, or looking to strengthen your foundation and grow with confidence? This webinar will help you build a clear understanding of what systems engineering is, what the day-to-day work looks like, and what it takes to succeed.
In this webinar,Chris Unger, INCOSE Healthcare Working Group Lead, and Vincent Balgos, Sr. Director of Solutions & Consulting at Jama Software, share practical guidance for getting started and building a strong foundation for long-term career growth in the medical device & life sciences industry. From core responsibilities and daily work to the hard and soft skills that matter most, this session will help you better understand the role and how to grow in it.
What You’ll Learn:
What systems engineers do day to day, and the core responsibilities of the role
The essential hard and soft skills that help systems engineers succeed
Practical guidance for navigating a new or evolving systems engineering role
Strategies to keep learning, growing, and building confidence in your career
Real-world insights from experienced systems engineers you can apply right away
Take the first step in your systems engineering journey and register today.
Vincent Balgos: Thank you for attending. My name is Vincent Balgos. I’m the Senior Director of Medical Device Solutions here at Jama Software. And today I’m happy to have a conversation with Chris Unger. Chris, would you like to introduce yourself?
Chris Unger: Yeah. Hi, I’m Chris Unger, the retired Chief Systems Engineer for GEA Healthcare. I spent five years in defense and then 40 years in medical device, and I’m the head of the INCOSE Healthcare Working Group.
Balgos: Great. And Chris, we just finished up with the 11th annual systems engineer, sorry, INCOSE Systems Engineering Conference. I’m curious, could you share with our audience a little bit about the history, but also what exciting events and key takeaways that you had from this year’s event?
Unger: Sure, absolutely. Thank you, Vincent. Yeah, we started 11 years ago in Chicago when AAMI created the TIR45, on how to be agile in healthcare while working with the FDA. And we had a concern that would be considered software only. We wanted to have more iterative spiral development. And it was 15 people just by invitation only, and it has grown now to the last two years of over 200 people and many, many tracks. And particularly exciting to see the evolution in topics. For example, compliance was one of our early topics, and now it’s not there. We don’t worry about compliance. What we’re interested about is customer focus, and the AI track has grown from 10 people to 50 people in the room. So very exciting evolution of topics.
Balgos: Yeah. Where do you see systems engineering growing within the MedTech area?
Unger: Yeah. Compared to 40 years ago, devices were fairly complex. CT had hardware and software, hardware chemistry and mechanics, and electronics, and some software to now, with the growth of software, it is incredibly complex. Layers, you’ve got algorithms, four levels of control theory, and so many overconstraints. So that’s where to take, for example, a thermal problem. Is that a dissipation problem in electronics? Is it a thermal cooling problem? Is it a duty cycle problem of like, “I’m spending too much time in high performance, and I should coach the customer in only using the high dissipation modes.” So those kinds of system trade-offs are becoming much more important, but that’s the baseline of the last five years. Going forward with AI, the implementation speed’s going to go way, way higher. I even saw that 10 years ago, when we had more of the beginning of the digital twin.
In the past, mechanical engineers had time to do a design, ship it out, and get it back. Now it’s like with digital twin, they do it at a design, and they get the answer back the next day. So you really did need to make sure that you understood the incremental approach to avoid rework. AI is going to take that to the next level. The ability to have AI do your circuit science for you, do your software design, the speed’s going to go up like 10X, and systems engineering has to go off and be the orchestrator, the conductor of the orchestra, make sure when everybody’s going so fast, we still stay aligned and focused on the customer.
So in those cases, being able to work with marketing, trust marketing, but also know the customer’s needs and be able to take the value to the customer, divided by being pseudo-analytical, divided by the cost to implement times the risk. Something might take a certain amount of effort and have a 10% chance of succeeding. So the effective cost of the company is 10X bigger. Being able to tie that all together and make sure everybody is focused on the most valuable work for the next week, not the next six months. The speed of those decisions is going to be huge going forward.
Balgos: Yeah. And that system thinking approach is what really brings system engineers here to help-
Unger: Sorry to interrupt. But systems thinking plus the ability to communicate it in words, taking the customer’s needs and translating that down into words that an electrical software engineer can understand. That translation, speaking both worlds together, is critical.
Balgos: So yeah, not just thinking, but then translating and helping drive these more AI-enabled teams to make quicker decisions and safer and more effective healthcare products. Great. Anything else on the AI front that excites you with MedTech coming up?
Unger: Yeah. The ability to have AI take some of the tedious work out, how to write a good requirement, A, can do that really well. It’s also really easy to learn new techniques. I was talking to the CEO of a startup about a use case, and that’s something that software people use for a while, systems people didn’t, and she didn’t understand what it was. So she was trying to get an example for a company, and she gave AI, “Give me a use case for an infusion pump in this problem.” And it gave her a 10-page report, really good quality, not AI, which doesn’t know what infusion up is. So the ability to say, “Oh, I’d like to learn this technique. Can you do this for me?” Your speed of learning will be really fast. The problem then is you’ve got to make sure that you know how to review those things.
So again, the ability to do good reviews and have good conversations with people is the skill you need now. I was talking about with a engineer, that example of the board where we didn’t use four boards to one, what’s the effect on thermal flow? What’s the effect on EMI/MC? Did you take a lot of EMC and suddenly put it into one area, so the EMC issue is bigger? That kind of skill that you should be using to converse with engineers who are brilliant in their area, but don’t understand other areas, will be much more important even when talking to the AI agents.
Accelerate Compliance and Requirements Review with AI
Expert Recommendations at the Click of a Button
Reviewing requirements and their associated compliance material is an essential component of developing a quality product. However, review time can often be consumed by arguing over the minutiae of syntax, grammar, and other secondary aspects of a requirement, rather than the technical subject matter. For many teams, this means their subject matter experts (SMEs) are trapped in debate rather than informing design and progressing the development cycle. With the advent of Large Language Models (LLMs) and Model Context Protocol (MCP), the engineering industry is on the verge of optimizing away from these debates and focusing on critical technical progress instead. By tactically prompting and developing tools that can provide a first-pass review, engineering teams can:
Reduce overhead associated with first pass and draft reviews of requirements data
Free SMEs from the monotony of syntax and grammar
Empower junior engineers to improve their requirement development skills
Hone Engineering Expertise with Personas with AI
Artificial Intelligence (AI), particularly Generative AI, has modernized rapidly. Engineering teams are now deploying personas and agents into their workflows. The use of AI provides many clear benefits; however, there are also looming pitfalls. I have personally noted, while working with customers and in my engineering career, that using a deliberate method that forces the human back into the loop provides more effective results than directly allowing AI to modify requirements.
This is where Jama Connect’s integration with an LLM through MCP improves the engineering workflow. Engineers can develop standardized prompts and personas to review data. With the data reviewed and AI recommendations provided, junior engineers can step back in and make improvements prior to discussing the technical details with SMEs. Therefore, improving the requirement’s first draft quality. Simultaneously, this approach reduces the cost of creating quality requirements by decreasing the reliance on SMEs early on in the process.
Rapidly Deploy AI into Requirements Development Workflows
Throughout engineering, there are common roles and expertise that apply to requirements development. For example, there are known syntactical rules posted by many organizations for how to author a requirement. Rules from each of these sources can be applied systematically to help review requirements. Thus, it reduces debate over whether the requirement is syntactically correct.
Similarly, many roles throughout engineering are well defined by guiding documents, standards, and best practices. Most of these documents are public and accessible via the internet. Therefore, it is straightforward to develop personas that mimic an SME from their respective domain of expertise. These personas can be as simple as textual prompt files or as complex as logic-based scripts that are run and utilized by an AI integration into Jama Connect. For instance, a mechanical engineering persona is informed by NASA-STD-5001 and MIL-STD-1522, among a handful of others, to produce meaningful recommendations.
When authoring a persona, teams can do this natively in Jama Connect as a specific Item Type that includes the response format, list of documents the persona is built around, and other pertinent details. By integrating this information directly into the project where the requirements reside, teams are able to assess and version control each persona and related information. With personas developed, teams can rapidly deploy and redeploy canned expert reviewers to provide recommendations to their requirements. My recommendation is to pair these personas with a custom field within the requirement items. This allows Jama Connect users to see the recommendations made per version of the requirement.
As depicted above, the recommendations from the AI review are simple to understand and actionable. An engineer can process an update to the requirement and execute an additional run of the deployed personas to confirm the updates are satisfactory. Users can feel confident in early drafts of requirements due to this feedback and confirmation cycle. This also enables quick iterations prior to requiring time from SMEs.
A key objective of this approach is to reduce AI hallucinations by directly modifying technical engineering requirements that guide complex design, integration, and test. By doing so, teams reap large benefits through the recommendation cycle, while also minimizing the chance of a late failure due to misguided AI inputs.
The goal of this approach is to reduce time spent on initial requirements drafting. Doing so allows teams to focus their resources on early prototyping, compliance assessments, and other typical early-stage engineering efforts that often become truncated due to requirements development and analysis. As functionality like this progresses, new ways to ensure accuracy and reduce overhead will continue to arise. Keep an eye out for continued explanations and approaches to improve your requirements development and review with Jama Connect and AI.
From Requirements to Test Coverage – Using AI to Strengthen Traceability and Validation
Engineering teams frequently identify verification and validation gaps late in the development process — often during testing, audits, or certification reviews — when addressing them becomes both costly and disruptive. These challenges often stem from earlier stages, where unclear or inconsistent requirements hinder the creation of effective validation scenarios and disrupt the ability to maintain robust traceability between requirements and tests.
Katie Huckett: Welcome everyone, and thank you for joining today’s webinar, From Requirements to Test Coverage: Using AI to Strengthen Traceability and Validation. Today, we’re going to look at a very practical engineering workflow and how improving the clarity of requirements can directly improve validation, coverage, and traceability. Many engineering teams experience problems late in the lifecycle during testing or audits. What we’ll show today is that those issues often originate much earlier in the requirements themselves. I’m Katie Huckett, product line manager for Jama Connect Advisor™. I lead the overall vision and strategy for AI at Jama Software.
When validation failures appear late in the development lifecycle, teams often assume the testing phase is the problem, but in many cases, the root cause started much earlier in the requirements. If requirements are ambiguous or incomplete, engineers may create tests that don’t fully validate the intended behavior. That gap may not become visible until system testing or certification activities, when fixing the problem becomes much more expensive. Before we go any further, we’re curious about your experience. Where do validation gaps typically surface in your organization? Go ahead and select the answer that best reflects your experience.
Many teams find that these gaps surface during system testing or audits, which means the issue has been present for a long time before it becomes visible. Now, why does this happen? There are several reasons these validation gaps occur. One common issue is ambiguous language. For example, if a requirement states that the system should load a page quickly, what does that actually mean? Different engineers may interpret that requirement differently, which leads to inconsistent validation. Another issue is an incomplete requirement structure, where key details needed for validation are missing. Finally, relationships between requirements and tests are not always maintained consistently as systems evolve.
Huckett: This is the example requirement we’ll use throughout today to illustrate this workflow for a hearing aid surgical installation change. “The system should try to ensure that the doctor performs the surgery in three or more sequential stages if needed and completes it before they are done.” At first glance, this seems okay, but it leaves several open questions. What is it or they? How many stages are actually required? How should we validate that the behavior meets the intended design? These kinds of questions are common when requirements are written quickly or evolve over time.
The first step in strengthening validation coverage is improving requirement quality. AI-assisted quality analysis can evaluate requirements and identify issues such as ambiguous language or structural inconsistencies. This helps engineers catch potential problems earlier, before downstream work begins. Now, let’s look at how this works in practice. So let me start here by going into my system requirements, and you can see my surgical installation change requirements right here at the top. All right, let’s go ahead and run an analysis on this requirement. All right, let’s take a look at what the analysis found. And as a reminder, this isn’t about making requirements perfect; it’s about identifying issues that can cause confusion downstream in design, testing, and validation.
Huckett: So right away, you can see we’re flagging multiple issues across INCOSE and EARS guidelines. That’s usually the first signal; if a requirement triggers this many rules, it’s likely going to cause problems later in the lifecycle. One of the first things flagged is the use of “should” and phrases like “try to ensure.” That’s a problem because it weakens the requirement. It’s no longer clear whether this is mandatory or optional. And if it’s not clear, it won’t be clear when someone tries to validate it later. We’re also seeing logical conditions like “or” and “if needed.” These introduce ambiguity because they allow multiple interpretations of what the system is actually expected to do. That’s where teams start making assumptions, and different assumptions lead to inconsistent implementation and testing.
And then again, we have pronouns like “it” or “they.” This might seem minor, but in complex systems, unclear references can make it difficult to trace exactly what behavior is being described. That becomes especially important when you’re trying to maintain traceability across requirements and tests. So individually, these issues might seem small, but together they make the requirement hard to interpret, harder to validate, and harder to trace. And that’s where we start to see gaps showing up later in testing. So instead of manually rewriting this from scratch, we can use our Requirement Refinement feature to generate a cleaner version of this requirement. So let’s go ahead and kick off that process. Okay, here’s the suggested rewrite. We have a couple of options here. “The system shall facilitate the surgery to be conducted in a minimum of three sequential stages,” and “The system shall ensure the surgery is completed within the designated timeframe.”
Unlock Static Data and Accelerate Development by Using Raiqon PDF Converter with Jama Connect
Raiqon and Jama Software have partnered to address the friction caused by static PDF files in agile development environments. Although PDFs remain a standard for exchanging product requirements and RFPs, they often stall progress due to a lack of structure and fine-grained traceability. This disconnect forces teams to rely on cumbersome manual processes that increase the risk of error, slow down product development cycles, and make rigorous change management difficult to achieve.
Using Raiqon PDF Converter with Jama Connect provides an elegant bridge between legacy documentation and modern digital engineering. PDF Converter digitizes static text, complex tables, and images into structured ReqIF, Word, or Excel data files that maintain the original hierarchy and context. By automating this conversion, organizations can ensure that every requirement is digitized accurately for importing into Jama Connect, using Jama Connect Interchange™ for ReqIF.
KEY BENEFITS
Automate Requirement: Imports Replace tedious manual data entry with intelligent parsing that digitizes PDF content into structured requirements, accelerating R&D, saving valuable engineering time, and improving quality.
Maintain Data Fidelity: Ensure complete accuracy by importing tables, images, and formatting exactly as they appear in the source document for compliance and add searchable metadata for efficiency.
Scale Document Processing: Handle large-scale projects easily with a robust solution capable of processing documents with more than 1,000 pages.
Streamline Compliance: Convert isolated document text into traceable items within Jama Connect, supporting rigorous regulatory standards and improved risk management.
The Raiqon PDF Converter can be used as SaaS in the secure Raiqon cloud or installed in private clouds or even on premises (requires availability of GPU). After uploading a PDF document to the PDF Converter, advanced algorithms identify and segment requirements, headings, and visual elements. Optical character recognition (OCR) is applied to capture data trapped in images. Users can review the parsed content, adjust hierarchies, or correct text classifications to ensure precision. Once approved, the software exports a clean ReqIF, Word, or Excel file that is mapped to specific fields, allowing for a smooth import into Jama Connect, directly for Word and Excel, and using Jama Connect Interchange for ReqIF, that retains all structural logic and relationships.
To learn more about how using Raiqon PDF Converter with Jama Connect can reduce time and improve quality of your product development, visit jamasoftware.com
LEX Diagnostics Boosts Efficiency by Modernizing its Requirements Tool with Jama Connect
“It’s very compatible with the sort of startup model where everybody will be doing a little bit of everything. The person with the best skill set is the one who solves a particular problem.” – Tim Schuller, VP of Engineering, LEX Diagnostics
About LEX Diagnostics
LEX Diagnostics is redefining point-of-care diagnostics with its ultra-fast PCR system. Their launch product, the VELO system, delivers positive results for Flu A, Flu B, and COVID-19 in as little as six minutes, enabling cost-effective decisions during a single appointment.
Customer Story Overview
After inheriting an existing requirements management tool, LEX Diagnostics sought to modernize their approach. Switching to Jama Connect provided a user-friendly platform with direct product support and flexible licensing that aligned with their agile goals.
With Jama Connect, Users Experience:
A Modern, Intuitive Interface that empowers users to manage requirements, create documents, and enhance collaboration without a steep learning curve.
Flexible Licensing and Widespread Adoption that allows the entire team to contribute to projects, creating a single source of truth and improving internal knowledge sharing.
Responsive, Expert Support that provides clear answers and reliable timelines, saving weeks of project time and eliminating administrative delays.
LEX Diagnostics encountered hurdles in integrating their existing tool with their agile, startup environment. The team identified several areas where an improved solution could better support their workflows and rapid development pace.
Need for Responsive Support Jama Software’s flexible support model was a key advantage at important points in LEX’s development journey allowing the company to avoid manual workarounds which had historically been necessary and highlighting the importance of a partner that provides direct and timely product support.
Complexity Impacting Usability The LEX team found the Jama Connect interface easy and intuitive to navigate, which encouraged adoption by users who weren’t full time administrators resulting in the tool being more widely used across the organization. Jama Connect reduces the steps required to execute routine tasks, saving LEX significant time and money.
Need for Scalable Licensing Startups like LEX thrive on agility and collaboration, requiring tools that adapt to their dynamic workflows. Thanks to a flexible licensing model, Jama Connect allowed the entire team to participate directly in the development process, ensuring that critical reviews and updates happened within the platform itself. The software removed barriers to access and kept everyone aligned with a single source of truth.
“Our head of software…just figured Jama Connect out himself in about 15 minutes. It’s just night and day with simplicity.” – Tim Schuller, VP of Engineering, LEX Diagnostics
Solution
LEX Diagnostics decided it was time to update its requirements management tools and chose Jama Connect, supported by internal champions with positive prior experiences with the platform.
Seamless Onboarding and Hands-On Support: Following a trial where the team could test the platform’s full capabilities, Jama Connect’s tailored onboarding and hands-on support ensured a smooth transition.
An Intuitive, User-Friendly Platform: The simplicity of Jama Connect offered immediate value to the engineering team, allowing them to focus on innovation rather than tool management.
A Flexible Licensing Model: Jama Connect’s flexible licensing model, including unlimited reviewer seats, suited LEX Diagnostics’ startup environment, fostering collaboration across departments.
“It’s a useful confidence boost to see that the workflows we’ve built in Jama Connect closely align with standard medical device and regulatory workflows, reinforcing trust in our approach.” – Tim Schuller, VP of Engineering, LEX Diagnostics
Since adopting Jama Connect, LEX Diagnostics has seen significant improvements in its processes, team morale, and confidence in meeting regulatory requirements.
Improved Adoption and Internal Knowledge: Flexible licensing has driven widespread adoption. Teams now use Jama Connect for internal software and hardware development — projects they previously managed in disparate documents. “It’s very compatible with the sort of startup model where everybody will be doing a little bit of everything,” Schuller explained. “The person with the best skill set is the one who solves a particular problem.”
Increased Efficiency and Reduced Timelines: The direct support and user-friendly interface have streamlined administrative tasks. Schuller estimates the responsive support from Jama Connect saved four to five weeks of potential delays. When the FDA requested further details during review of their 510(k) submission, generating documents from Jama Connect was faster and easier.
Enhanced Regulatory Confidence: With built-in templates aligned with standards like ISO 14971, Jama Connect gives the team a validated framework for their workflows that has provided a “useful confidence boost.” The ability to easily version changes within the platform has also freed them from manual paperwork tracking and potential audit complexities.
