What Requirements Were Verified in Software Testing?

Questions Starting Next to Pass Marks

The test report is filled with a pass mark.

The developer explains that the system is functioning normally, and the reviewer asks what requirements were verified.

Although there is a test number, several files need to be reopened to check if the scope of requirements and conditions verified by that test is correct.

Today’s question is not how many tests were conducted but rather whether we can trace the expected behavior to the actual results verified.

Knowing that there is a connection table and judging that this connection sufficiently explains the content are different.

Even if the requirement number is in one column, if the test content only addresses some conditions, the remaining parts still exist.

This article serves as a practical guide for those developing or reviewing test materials for medical device software.

While referencing the FDA’s software submission guidance, the notes, checks, and cases below are MedQraft's own composition.

It does not constitute a complete verification plan for any specific product or a legally mandated submission form in domestic regulations.

It does not imply that regulatory support software for business purposes automatically qualifies as a medical device.

The Meaning of the Connection Confirmed in Official Documents

The FDA's 2023 guidance describes the traceability between software requirements and related documents in section VI.D.

Section VI.H discusses expected results, observed results, judgments, and related reports, while VI.I deals with the version history of the tested software.

Verification includes review and analysis activities in addition to testing; thus, simply passing a test does not elucidate the entire software validation process.

FDA Official Document

This document is a non-binding recommendation from the United States.

The front part of the currently provided PDF advises checking the QMSR effective from February 2, 2026, so the expressions of past QSR provisions in the text do not translate directly to current obligations.

Here, rather than summarizing the entire submission document, the focus is on how practitioners read the evidence.

The results record connects to the conditions under which the expected behavior was verified.

During the next meeting, select a line from the connection table and open the actual files.

Check whether the current revision of the requirements and the revision referenced by the test are the same, and whether you can find the corresponding action in the result files.

By reading a complete line, any missing information during the completion of the connection table may be revealed.

Breaking Down Requirements into Observable Actions

The statement "raises alerts to users when a problem occurs" provides direction but makes it difficult to determine what to verify.

You can list questions about what state is considered a problem, who should see what indication, and what states other screens or values should remain in.

This does not mean applying the same statement to all devices; instead, it’s a question to confirm whether the team imagines the same action.

For example, in the following sensor case, we separately review 'notifying of the disconnection state' and 'how the existing measurement values are displayed.'

If only the functionality to indicate connection status is verified, and it is judged that the entire meaning of the screen has been verified, one inquiry may be omitted.

The review scope varies depending on the risks and usage context of that functionality.

Questions for Reading Requirements	Questions for Reading Tests	What to Look for in Records
When is that action necessary?	Was the same state created?	Input, precondition, environment
What needs to be displayed or processed?	Was that outcome actually observed?	Expected results and observed results
To which configuration does it apply?	Was it executed with that configuration?	Model, settings, software version
What remaining questions are there?	Are there conditions not verified?	Non-executed, anomalies, follow-up review

The table serves as a self-tool for review discussions.

There is no fixed structure that requires one test to be attached to each requirement.

A single requirement can be validated by multiple tests, and one test can cover multiple requirements.

However, when multiple numbers are linked, it should be possible to read at which step each content was verified.

Hypothetical Case: Sensor Connection Lost

This is a hypothetical situation.

A device is being developed to display the values from a sensor on the screen.

The team decided that when the connection is lost, the user must become aware of that state.

During the review, it was found that previous measurement values remain visible on the screen.

Even with a disconnection notification, there arises a question whether users might interpret that value as the current value.

Both the disconnection notification and the display method of previous values are separate verification questions.

Here, it does not imply that the faded waveform shown in the diagram is the correct answer.

The method of displaying values should be determined based on the intended use of the product and risk assessment.

This section examines how to connect approved actions with testing conditions.

No arbitrary specified delay time or common passing score is included.

Hypothetical Review Items	Current Evidence Acquired	Areas Still to be Verified
Indication of connected state	Record of executing normal connection state	Does not address the disconnection state
Notification of disconnection state	Disconnection display screen	Whether the state of the previous value aligns with requirements
Behavior after reconnection	Test draft only created	Check actual execution and new data display

This table purposely leaves certain states unresolved.

Having a draft test and having executed it are different, as is fulfilling expectations versus execution.

Filling in blanks with 'pass' to increase completion rates can obscure what needs further verification for the next person.

Leaving Judgments and Observation Records Together

Business notes can compile requirement ID and revisions, test ID and procedural revisions, and the identification details of the tested software.

Subsequently, include expected outcomes, actual observations, judgments, and the location of evidence files.

Rather than copying lengthy logs into each document, linking parts of the original records will facilitate easier reviews.

For instance, it is better to write not just 'confirm normal display' but to specify what preconditions were there, what operations were made, and where the results were read from the screen or logs.

Even if screen captures are needed, it should separately be considered whether the screen alone narrates the sequence or internal state.

Conversely, the mere abundance of logs does not lead to the assumption that the visible actions for users have been verified.

Unexecuted conditions are recorded as non-executed, and results needing interpretation are categorized as needing further review.

Rather than overwriting failed records with new passing records, it's more insightful to maintain a trail of what was fixed and in which version it was revalidated to comprehend the reasons for changes.

This note does not replace testing documents; instead, it aims to facilitate the discovery of testing evidence.

If a Line Changes, Review Linked Tests Again

Let’s assume that the rule displaying previous values has been changed in the earlier hypothetical case.

The team revises related requirements and screen designs, checking if that change might also affect the disconnection notification and reconnection actions.

At this point, the connection table becomes more than just a collection of modified document numbers; it serves as a starting point for discovering the range needing another review.

Moving to linked tests based on modified items allows differentiation of verification scopes and unresolved issues.

MedQraft’s suggestions are as follows:

First, briefly write the changed meaning and find the associated designs and tests.

Next, verify with the responsible person if there are functionalities using the same data or states that are not directly linked.

Finally, distinguish between reasons needing further confirmation and those judged unnecessary.

Assuming the existing connection table is perfect risks missing newly formed relationships.

This note aims to establish verification ranges in accordance with the impact and risks of changes, rather than mechanically repeating all tests or just directly linked ones.

The actual scope of regression testing should be determined by the development and quality personnel in consideration of the product and changes.

Follow a Line Thoroughly in Review Meetings

1. Can two people reading the requirements envision the same input, state, and output?
2. Which part of the requirements does the expected result of the connected test verify?
3. Are there states like disconnection and recovery needing review in addition to normal conditions?
4. Does the result record identify the tested software and settings?
5. Are non-executed and failed changes distinguished from passes?
6. When requirements change, can you describe the verification scope to be checked again?

Instead of starting with an extensive form, begin by selecting an important function and opening the record from requirements to actual documentation.

Organize unidentified evidence, differing revisions, and insufficient explanations, then supplement them according to the team's document structure.

Related Articles: Conditions to Check When Comparing Medical Device Performance Test Results, Linking Evidence in Medical Device Risk Management.

Although this article discusses a topic separate from software testing, it can review the questions regarding scope and evidence together.

Reference Materials and Scope of Writing

• FDA, Content of Premarket Submissions for Device Software Functions, published June 14, 2023.

Definitions, VI.D, VI.H, VI.I, and the QMSR guidance in the current PDF were verified.

Official Document

• Verification date: September 28, 2026.

This explanation, referencing U.S. submission recommendations, does not define regulations applicable to specific states or products, nor does it finalize the overall software development process.

• The sensor case, tables, and diagrams are composed by MedQraft.

No actual test results or customer case examples of specific products were utilized.

This does not promote the functionality or certification achievements of any specific product.