Introducing SPK AI Launchpad
Hi, I’m Carlos with SPK and Associates.
Today I want to show you something we’ve been working on called SPK AI Launchpad. The idea is pretty straightforward.
Engineering organizations already have systems for managing requirements, testing, risks, and development work. But getting information across those systems, understanding it, and acting on it can take a lot of time. What we’ve done is bring AI directly into that engineering environment.
Demo Setup and the FlowGuard Project
For this demonstration, we’re using Microsoft Teams as our interface, Azure AI behind the scenes, and Jama Connect and Atlassian Jira as our engineering systems. We’ve also incorporated engineering knowledge, including INCOSE and EARS guidance, to help evaluate and improve requirements. And because we’re working in regulated industries like medical devices, we’re not bypassing established engineering review and approval processes. We’re building AI into those processes.
Let me show you how it works. Let’s take a quick look at the engineering project we’re using for this demonstration. This is FlowGuard, a sample medical device project we’ve built in Jama Connect. We’ve got our system requirements along with engineering specifications and protocols that define how the device is expected to behave.
We’ve also organized the risk management information here, including the hazards and risk controls associated with the device. The project brings together the requirements, engineering documentation, and supporting verification information in one place. And that’s really our starting point.
Connecting Jama Connect, Jira, and Microsoft Teams
We’re going to use the information already in Jama and show how SPK AI Launchpad can analyze it, identify improvements, and work within the existing engineering process. Before we do that, let’s take a quick look at Jira.
Here’s our Atlassian Jira project for Almeida Med. We’ll use Jira to track engineering work that comes out of our AI-assisted requirements analysis. SPK AI Launchpad can prepare those tickets automatically, with engineering approval before they’re created.
Now let’s move into Microsoft Teams and see how this works. Here we’ve integrated our SPK AI Launchpad application directly into a Microsoft Teams channel. In this case, we’re working in our engineering team’s channel, but Launchpad can also be added to other channels or invited into conversations. Engineers can interact with it right here alongside the rest of their team.
Underneath the hood, we’ve built an MCP server that connects Launchpad to Jama, Jira, and our other engineering capabilities. And we’ve given it quite a few tools to work with. Let’s take a look at those tools.
Because we’re working inside a Teams channel, we can invite SPK AI Launchpad into the conversation simply by mentioning the application, and then we can interact with it directly using either natural language or specific commands. In this case, I’m going to use the tools command to see what’s available.
Remember, underneath the hood, we’ve built an MCP server that connects our AI application to our engineering systems. Here we can see the tools that we’ve instrumented, including extensive support for Jama Connect and Atlassian Jira. These aren’t just general AI capabilities. They’re actual operations that allow Launchpad to retrieve requirements, examine projects, follow relationships, and interact with engineering records. And as you can see, we have quite a few of them. Now, let’s put some of these tools to work and examine an actual requirement in Jama.
Evaluating a Requirement in Jama Connect
Here I’m asking SPK AI Launchpad to retrieve an actual requirement from Jama Connect and evaluate it against our engineering knowledge base. We’re looking at an air detection requirement for a medical infusion pump. Launchpad retrieves a requirement and applies INCOSE and EARS guidance to evaluate its clarity, completeness, and testability.
Now, for the sake of time, I’ve sped up this portion of the demonstration to get to the results. We’re running Launchpad locally on my laptop today, so there’s some processing time involved. We expect significantly better performance once it’s deployed to dedicated cloud infrastructure and properly tuned.
And here are our results. The original statement describes what the clinician needs, but it doesn’t define what constitutes a significant air bubble or exactly how the pump should respond. Launchpad recommends a more precise system requirement, including measurable engineering parameters that still need to be defined. It also provides a redline comparison, making it easy to see what changed and why. Importantly, this is a recommendation, not an automatic modification to Jama. The engineering team remains responsible for reviewing and approving any proposed changes.
Proposing and Reviewing Requirement Changes
Next, let’s look at how Launchpad manages proposed changes through a controlled engineering workflow.
Now let’s look at how SPK AI Launchpad manages proposed engineering changes. Here we’re working with a different Jama requirement, this time focused on flow delivery for our medical infusion pump.
Launchpad will analyze a requirement and generate a recommended improvement along with a redline comparison showing exactly what’s changing. And when it completes, notice that we will also have a “Prepare Jama Proposal” action. And that is where we’ll move beyond simply analyzing requirements and begin managing proposed changes through a controlled engineering workflow. Now I’ll select “Prepare Jama Proposal.”
Launchpad creates a tracked proposal in its own database, capturing the original requirement and recommended change. Notice the status, “Staged, not published.”
Publishing a Proposal to the Jama Sandbox
Nothing has changed in Jama. Publishing to the separate Jama sandbox is our next controlled step. Before we publish our proposal, let me show you where it’s going.
Here in Jama Connect, we have our original Almeida Med engineering project. We’ve also created a corresponding project specifically for AI-generated proposals called the AI sandbox. This keeps proposed changes separate from our controlled engineering requirements. When we publish, Launchpad creates a new item in the sandbox, retaining the identity of the original requirement and its synchronization relationship. That allows engineers to review proposed changes before anything is applied to the original project.
Back in Teams, I’ll select “Publish to Jama Sandbox.” Launchpad shows us the proposal, the original requirement, and the destination project. Notice that publishing requires a separate confirmation. Nothing has changed in Jama yet. Let’s confirm the publication.
Launchpad begins transferring our proposed requirement into the separate Jama AI sandbox. This is an asynchronous operation, so we can continue working while Launchpad completes the publication and establishes the synchronization information. Next, we’ll open Jama and examine the result.
Back in Jama, I’ll refresh the AI sandbox. The proposal we prepared and published through Teams is now here as a Jama requirement organized under system requirements. Opening it shows the proposed revision to our flow delivery requirement. This takes the analysis we performed using INCOSE and EARS guidance and brings it into the engineering environment for review.
Now I’ll expand Jama’s synchronization panel. The proposed requirement retains a connection to its original in the Almeida Med project. In the redline view, we can examine the wording changes alongside the original supporting content. That lets an engineer evaluate whether the proposal improves clarity and testability, preserves the intended behavior, and leaves anything that still needs clarification.
Publishing the proposal hasn’t changed the original requirement. The mainstream remains authoritative, and the engineering team controls which changes, if any, are synchronized back. If our process requires a formal review, we can select “Send for Review” and route this AI-assisted proposal through Jama’s review cycle. That gives the engineering team an opportunity to evaluate the changes and resolve feedback before updating the authoritative requirement.
For this demonstration, we’ll assume that review has already been completed. I’ll use the down arrow here to synchronize the proposed changes from the AI sandbox back to the original requirement in the Almeida Med project. This is the human-controlled step. The AI prepared the proposal, and now we’re choosing to apply the reviewed changes to the mainstream.
Assessing Requirements Across the Project
We’ve just walked through improving one requirement. Now let’s expand that to the engineering requirements across the project. From Teams, I’m asking Launchpad to assess the main requirements in Almeida Med using INCOSE and EARS guidance, score each one, and generate the quality reports, including an Excel workbook.
The scope here is the current mainstream content in Jama. We’re keeping the AI sandbox out of the assessment, and we’re not changing any requirements. Each requirement is assessed individually, with findings brought together into a project-wide view. We’re looking for issues that affect engineering quality, including ambiguous wording, missing conditions, unclear acceptance criteria, and statements that are difficult to verify.
The scores help prioritize attention. The supporting findings explain what an engineer needs to investigate.
This takes a little time because we’re working through the full set rather than asking for a general summary. I’m briefly bringing the processing window into view so you can see the work continuing behind the scenes. Normally, the engineer can stay in Teams. The value is a consistent first pass across the requirements, giving the team a concrete starting point for review while leaving the engineering decisions with the people responsible for the product.
Reviewing the Assessment Reports
The assessment is complete, and Launchpad has returned the report downloads. I’ll open the Excel workbook so we can explore the results in more detail. This gives us a working review tool. We can sort and filter the findings, focus on particular requirements, and use the recommendations to plan follow-up work.
The reports draw from the same assessment, keeping the project summary and individual findings consistent. The executive dashboard summarizes the assessment of 128 requirements. It shows the quality rating distribution alongside the engineering disposition, separating acceptable requirements from those needing further review or remediation. That distinction helps us understand both the overall picture and where to focus the team’s attention. A quality score supports that decision. It doesn’t replace engineering judgment.
The remediation register brings the problematic requirements together with their scores, identified issues, and recommended improvements. We can use the filters to concentrate on the findings that need action. In the full requirements assessment, we can examine the individual results and scroll across to the recommendations and suggested revised wording. Those are separate pieces of information. The recommendation explains what needs attention, while the suggested revision provides wording for an engineer to consider. Where information is missing, it still needs to be resolved by the team.
This brings us back to the workflow we demonstrated earlier. Identify an issue, develop a proposal, review it, and deliberately apply the accepted changes to the authoritative requirement.
Turning Assessment Findings into Jira Work
Now, let’s turn the quality assessment into engineering follow-up. I’m asking Launchpad to use the completed assessment, select the 10 problematic requirements with the lowest scores, and prepare one consolidated Jira issue in project AM, including the findings and suggested improvements.
Here’s the proposed issue. As I scroll through it, we can inspect the requirement identifiers, quality scores, engineering dispositions, and suggested revisions.
We’re reusing the assessment we already completed. This gives the team the context behind the remediation work without running another analysis. The preview gives me a chance to review the proposed content before creating anything in Jira. I’ll select “Confirm Create.” That explicit action authorizes Launchpad to create the issue.
The issue is now available, and Launchpad provides an “Open in Jira” button. We’ve carried the assessment findings into a single work item, including proposed wording and placeholders where engineering decisions are still needed. Creating this ticket does not apply those revisions to the requirements in Jama.
Let’s look at it in Jira. The team can now assign the work, track its progress, and review the proposed changes through its normal engineering process. Launchpad has connected the assessment to actionable follow-up while Jama remains the authoritative requirement system.
Critical-to-Quality Assessment and Evidence Gaps
For our final example, I’m asking Launchpad to assess critical to quality for the Almeida Med project, bringing together engineering requirements, risks, traceability, and verification evidence in one report. We designed the CTQ framework beforehand, defining the information to examine, the metrics to calculate, and the evidence needed to support the assessment. We then made that guidance available through our Azure knowledge base. Launchpad uses that framework to evaluate the actual records in our Jama demonstration project.
The reports are now available. I’m opening the PDF to review the results.
This is where a customer’s engineering process becomes practical. The assessment follows a defined methodology and organizes the supporting project information into a consistent deliverable. The accompanying Excel workbook provides another way to explore the findings with the engineering team.
The report shows a provisional health score of 6 out of 100 with 75% evidence coverage and a “Not Ready” status. The charts distinguish demonstrated evidence, unmet criteria, and information that remains unknown.
Scrolling into the register and detail cards, we can examine individual quality concerns, associated records, and evidence gaps that need engineering follow-up. Your engineering methods connected to your project data.
Thank you very much for watching SPK AI Launchpad. Please contact SPK and Associates to learn how we can help implement your engineering AI use cases.
