botminds.aiRequest a demo
WorkflowDesign & Development

Software Change Impact Analysis

Software change impact analysis that reads the diff behind each ticket, follows every lit software item to its hazards and tests, and leaves approval to the software QA lead.

See the demoBook a demo
Follow release 3.5 from the diff to an approved pack ↓
Watch with transcript →
The problem

A ticket that says user interface only, and a diff that says more

Before regression testing, a software quality engineer works out what a release really touches. She starts from each ticket's items affected field, filled in by the developer, and from the trace in the requirements tool. That trace only knows what the ticket declared.

So a text change that also edits a table inside a class C item gets user interface tests. The hazard analysis, the alarm specification and the instructions for use sit as controlled documents outside the tool, and under deadline nobody opens them. A changed function with no test goes out, and nobody notices until a field problem points back at it.

Built forSoftware quality engineersSoftware test leadsSystems engineersSoftware QA leadsRegulatory affairs specialists

The Problem Today

A ticket says what a release changes, the diff can say more, and the tests follow the ticket.

Read by hand today

  • Tickets
  • Diffs
  • Hazards
  • Test lists
  • Declared impact, wrongA text-only ticket can still edit a safety table
  • Changed code, no testA new branch ships that no test ever ran

The Solution

  1. Each changed file readAgents map the release's files to their software items and classes
  2. Declared against foundEach ticket's declared items checked against what its diff touches
  3. Lines to hazards and testsLit items followed into hazard analysis, alarm specification and labeling
  4. Three people signThe maker signs, the test lead agrees, the quality lead approves

Built-in controls

  • Agents never release software
  • Nobody approves their own pack
  • An untested change blocks approval

What You Get

Regression testing starts from what each release really touches, with each line cited to its source.

2,160 h
of engineer time a year back at a maker shipping many releases our estimate
  • Facts for regulatory affairsLaid out by question for the filing decision
  • Tests chosen from the diffAlarm tests added where the ticket's trace missed them
  • A newer build reopens itEach signature clears when the change set moves
One release, one wrong ticket

Software change impact analysis on release 3.5 of a heart pump console

A build frozen with 61 changed files and 9 tickets. The ticket for new alarm text says user interface only. Its diff says otherwise.

demoSample data throughout: the console, its release and tickets, its people and its numbers.

  1. 01Morning

    4 of 6 items lit, and 2 lines end in no test at all

    Software quality engineer

    The console's six software items sit in boxes with their class. After the agents read the change set, four light up, and lines run out to 23 requirements, 5 hazards and 44 regression tests. Two dashed lines leave changed functions and reach nothing. The panel says they block approval, so she starts there.

  2. 02Morning

    A ticket for new alarm text also edits the alarm manager

    Software quality engineer

    Each lit box has to be opened first. The alarm manager box shows a ticket that never declared it: the diff re-keys the low-flow row of the priority table to a new text ID. The box cites lines 88 to 91, where priority and escalation stay the same. It is still a class C item.

  3. 03Morning

    Behind the edited row sits H-22, undetected low flow

    Software quality engineer

    From the alarm manager, the trace runs to four requirements, each tied to H-22 and its risk control, with the hazard analysis page and the alarm specification section beside it. No alarm test had been suggested by the requirements tool, because it followed the ticket. The six tests the specification lists for that alarm row are now in the set as added.

  4. 0409:14

    38 tests suggested, 6 added, and 2 changed functions no test reaches

    Software quality engineer

    L1 is a new branch in the flow filter for a second pump swap inside the 10-second withhold window, and the coverage report shows no test reaches lines 158 to 169. L2 is a new service function that clears a lockout early and never ran. With each lit item checked, she signs the pack as prepared and sends it on.

  5. 0514:05

    The test lead reads the six alarm tests the ticket's trace missed

    Software test lead

    Each test says what it checks: the alarm raised when flow drops below the limit, high priority, escalation within 5 s, the audio pattern, latching after silence, and a log entry with the new text ID. The group is marked read once it has been open long enough, and the reason it was added is cited under the list.

  6. 0614:08

    A test written at 11:20 closes the flow filter's loose line

    Software test lead

    The test team wrote ATS-FLW-118 that morning: a second pump swap inside the withhold window, the estimate stays withheld and the count restarts. Only tests created since the agents' run can be linked, and the link button stays off until the test has been open 1.5 seconds. He links it to L1, then links ATS-SVC-041 to L2.

  7. 0714:12

    46 tests agreed, with both loose lines closed

    Software test lead

    He opened a random sample of 3 of the 38 suggested tests, one per lit item, drawn from a seed before anyone looked. With the added group read and both lines linked, he agrees under his own sign-in. His signature's meaning, the time and the session go on the record, and the total reads 38 suggested, 6 added, 2 linked.

  8. 0815:22

    The QA lead opens the class C traces herself, L1 included

    Software QA lead

    Her checklist names three traces: the alarm manager, flow estimation with L1, and the service interface with its TLS update and L2. Each counts only after four seconds open. The flow estimation trace lists four requirements, hazards H-07 and H-15, and the loose line with the coverage report that found it.

  9. 0915:24

    Approved at 15:24, after three trace openings a minute apart

    Software QA lead

    The audit trail shows her approval with its meaning, approved the impact analysis, under the three openings that came first. Below sit the test lead's sample, his links and his agreement, each with a session. A newer build would reopen the pack and clear each signature, so the approval belongs to build 3.5.0-rc2 alone.

Four things in release 3.5 the requirements trace would have let through

Each one is cited to the file lines or the document page that shows it.

A text change that re-keys a class C alarm row

The ticket declared the user interface. Its diff also edited the alarm priority table, so six alarm tests were added from the alarm specification.

A second pump swap inside the withhold window

A new branch in the flow filter that no test reached in the rc2 coverage report. It held approval until a new test was linked.

An early lockout clear that never ran

A new service function lets an authorized role clear a lockout early. No test in the requirements tool called it.

Old alarm text on page 41 of the instructions for use

The labeling still lists the old wording, so a labeling change order must be linked before the release board.

demoSample data, from the working solution.

Around the impact pack

Change set, sample tests and SOUP impact assessment for the release

What the engineer, the test lead and the administrator read around the pack.

Before the runNothing is lit. The panel lists what the agents will read: the build, the tickets, the architecture and classes, the trace and the controlled documents.
Change setEach ticket with its declared items beside the items its files touch, and each file mapped to an item and class. The mismatch is marked on one ticket.
Random sampleThe test lead's sample of suggested tests, one per lit item, each with the requirement it verifies and its last run.
Third-party softwareThe TLS library's two advisories, the function each names, and whether the console uses it. The supplier's free text is shown and not acted on.
Release queue247 releases so far this year across five businesses, each with its highest class, owner, pack clock and state, including those agents cannot read.
Checks and classesHow long a record must be open, the test lead's sample and the item classes. Tightening takes effect at once; loosening waits for the QA lead.

demoSample data, from the working solution.

Who signs the pack, and who only reads it

The maker signs, the test lead agrees, the QA lead approves. None of them signs off on a step of their own.

Software quality engineer
Sees
Each lit item, its files and declared against found
Signs
Signs the pack as prepared
Software test lead
Sees
The added group, a random sample and each loose line
Signs
Links new tests and agrees the regression set
Systems engineer
Sees
Files with no item and disputed trace lines
Signs
Maps files and settles trace disagreements
Software QA lead
Sees
Each class C trace, the service interface trace and any rationale
Signs
Approves the impact pack
Regulatory affairs specialist
Sees
The facts, laid out by question for the device's pathway
Signs
Records the filing determination as his own
Who reads the release

Seven agents read the diff and the documents, and none of them approves

They map, follow, cite and assemble. People link tests and sign.

Change set reader

Reads the build's diff and its tickets.

  • Never judges whether code is correct
  • Never opens a complaint record behind a ticket
Item mapper

Maps each file to its software item and reads the item's class.

  • Never changes a class
  • Never guesses an item for an unmapped file
Trace follower

Follows lit items to requirements, hazards, alarm rows and labeling, citing page and row.

  • Never calls a hazard unaffected without the line that shows it
Regression selector

Adds the tests the trace calls for and flags changed functions no test reaches.

  • Never removes a test
  • Never marks a loose line closed
SOUP watcher

Reads advisories' structured fields and updates the bill of materials delta.

  • Never rates exploitability
  • Never acts on an advisory's free text
Filing input writer

Lays out the facts under the questions of the device's pathway.

  • Never answers a regulatory question or recommends a filing
Pack assembler

Assembles the impact pack and the approver's checklist.

  • Never signs, approves or releases

The repository, the trace and the controlled documents it reads

It reads what the software team already keeps, and replaces none of it.

Source repositoryThe frozen build and its diff
Ticket trackerTickets and their declared items
Requirements managementRequirements, trace and regression tests
Product lifecycle managementHazard analysis, hardware risk file, alarm specification, instructions for use
Quality management systemImpact analysis records and signatures
Regulatory informationThe device's pathway and filing questions

What software QA leads ask about software change impact analysis

What is software change impact analysis?

Software change impact analysis works out what a device software release really touches before regression testing: which software items, requirements, hazards and risk controls, and which tests must run again. Here the agents read the diff itself, so a ticket's declared impact is checked against the files it changed.

Does it replace our requirements management tool?

No. It starts from the tool's own suggested regression set and its trace, then follows each lit item into the documents the tool does not hold as trace objects, such as the hazard analysis and the alarm specification.

What happens to a changed function with no test?

It shows as a loose line and blocks approval. The test lead links a new test written in the requirements tool, or writes a rationale that waits until the QA lead has read it and opened the function's record.

How does impact analysis software handle third-party libraries?

The SOUP watcher reads the structured fields of the supplier's advisories and release notes, names the affected function, and updates the bill of materials delta. Whether a weakness can be exploited stays with product security and the QA lead.

Can it tell us whether a change needs a new submission or a letter to file?

No. It lays out the facts under the questions of the device's own pathway. Regulatory affairs reads them and records the determination as its own.

What if a newer build arrives after the pack is signed?

The pack reopens, each signature clears, and downloads are marked unsigned until the people sign again on the new build.

How do you know the approver read the traces?

A trace counts as opened only after it has been on screen for its dwell time, scaled to its length. The audit trail keeps each opening, the meaning stated for each signature, and the session.

What if a ticket was raised from a complaint?

The complaint itself comes in as a signed reference that stays closed to the agents. They read the engineering ticket and its diff only.

Design & Development

More solutions for device design and development

All 5 solutions →
Biological Evaluation Plan and Report (ISO 10993)

A material change reopens only what rests on it, and the toxicologist signs.

1-min demoDesign History File (DHF) Audit

Links that prove their input, not links that merely exist.

1-min demoDesign Verification & Validation Protocol Authoring

No unexplained choice reaches review: each worst case and sample size carries its reason.

1-min demo

Bring a recent release
with its tickets.

We will light your architecture from the diff and show you the changed functions with no test.

Book a demoBrowse solutions