NQA-1 Software Quality Assurance: A Clear Subpart 2.7 Guide

NQA-1 software quality assurance is where organisations with a mature nuclear quality
programme most often find a hole. The hardware side of a QA programme is visible, inspected and
audited. The analysis code that sized the component, the spreadsheet that performed the calculation
and the firmware inside the instrument frequently sit outside the programme entirely — and all
three are in scope.

Where NQA-1 software quality assurance lives in the standard

The requirements are in Part II, Subpart 2.7, Quality Assurance Requirements for Computer
Software for Nuclear Facility Applications. Implementation guidance sits separately in Part IV,
as an application appendix rather than as requirements — a distinction worth keeping straight,
because auditors assess you against Part II and the guidance is there to help you get there.

Subpart 2.7 covers the working substance of a software quality programme: applicability and
classification, the software engineering activities across the lifecycle, and general requirements
including documentation. In practice that means a Software Quality Assurance Plan, controls across
acquisition, development, operation, maintenance and retirement, verification and validation,
configuration management, and problem reporting and corrective action.

What counts as software under NQA-1 software quality assurance

The scoping question is the one that decides how much work you have, and organisations habitually
scope it too narrowly. Software in scope typically includes:

• Analysis and design codes whose outputs support a safety-related design decision
  — thermal-hydraulic codes, structural analysis, criticality codes.
• Spreadsheets and scripts performing safety-related calculations. These are the
  most commonly missed items in the entire programme, because nobody thinks of a spreadsheet as
  software.
• Embedded firmware in instrumentation and control equipment performing a safety
  function.
• Software tools whose failure could go undetected and corrupt a safety-related
  output.
• Databases and configuration data where the data itself drives safety-related
  behaviour.

What is generally out of scope is software with no path to a safety-related outcome — the
payroll system, the site intranet. The boundary is drawn by consequence, not by technology, and it
should be drawn explicitly in the SQA Plan rather than left to be inferred.

The dedication route for software you did not develop

Most nuclear software is bought, not written. Software not produced under a quality assurance
programme compliant with the standard has to be dedicated, using the commercial grade
route in Part II Subpart 2.14 — the same discipline applied to hardware, with critical
characteristics identified and verified by accepted methods.

This surprises people, and it is the most consequential single fact about NQA-1 software quality
assurance. A commercial analysis code from a well-regarded vendor is not compliant simply because it
is widely used and well tested. Somebody has to identify what the code must do correctly for the
safety function to hold, and verify it. Our guide to
commercial grade dedication covers
how that process works.

Building an NQA-1 software quality assurance programme

Configuration management is the requirement that bites late

A nuclear facility has a design life measured in decades. The question an auditor will eventually
ask is which version of which code, with which input deck and which settings, produced the result in
the safety analysis — and whether you could reproduce it. Organisations that treat configuration
management as version control on source files, rather than as the traceable link between a result and
everything that produced it, fail that question years after the work was done.

Problem reporting connects to Part 21

A defect found in safety-related software is not only a software problem. It runs into the same
evaluation machinery as any other defect, including the 10 CFR Part 21 assessment of whether it
constitutes a reportable defect or noncompliance. Your software problem reporting process needs an
explicit hand-off there, rather than sitting inside the engineering team.

Where to start

1. Inventory the software first. Before writing a plan, find out what is actually in
   use. The list is always longer than expected, and the spreadsheets are always on it.
2. Classify by consequence. Decide what is safety-related and record the reasoning,
   because that decision is the scope of everything that follows.
3. Write the SQA Plan. It is the governing document and the one an auditor reads
   first.
4. Decide develop versus dedicate for each item. Anything acquired outside a
   compliant programme goes down the Subpart 2.14 route.
5. Fix configuration management before it is needed. Retrofitting traceability onto
   work already done is the most expensive remediation in this area.
6. Apply the graded approach. Not every item in scope carries the same rigour; see
   the graded approach in NQA-1.

Verification and validation is where NQA-1 software quality assurance is tested

Verification and validation answer two different questions, and conflating them is the most common
technical weakness in this area. Verification asks whether each stage of development correctly
implemented the stage before it — did the code implement the design, did the design implement the
requirements. Validation asks whether the finished software does what the safety application actually
needs. Software can be perfectly verified and still validate badly, because the requirements were
wrong.

For acquired software the same two questions apply, but you cannot inspect the development stages.
That is why the dedication route exists: you identify the critical characteristics of the code —
the physics it must model correctly, the range over which it must be accurate, the conditions under
which it is valid — and verify those directly, typically by benchmarking against known solutions
or against an independently developed calculation.

Independence is the other axis. Under a proportionate NQA-1 software quality assurance programme,
higher-consequence software attracts more independent verification: not the author checking their own
work, and for the most significant items not even the author’s own team. Where that independence sits
should be stated in the SQA Plan rather than decided case by case.

Test cases are records, not scratch work

The test cases used to verify safety-related software are quality assurance records. They need the
same control as any other record: identified, reviewed, retained and retrievable. Organisations
routinely treat test scripts as working material, delete the outputs once the test passed, and then
cannot demonstrate years later what was tested or against what expected result.

The practical rule is that a test which cannot be re-run, from the retained artefacts, by someone
who was not there, is not evidence. Retain the input decks, the expected results, the actual results
and the version of the software that produced them, together.

Software changes are design changes

A patch, a version upgrade or a change to a configuration file is a change to something the safety
analysis depends on, and it belongs in change control rather than in IT maintenance. The question to
ask before any upgrade is what previously verified results would need re-verifying — and if the
answer is not known, that is itself a configuration management finding.

Frequently asked questions

Where are the NQA-1 software quality assurance requirements?
Part II, Subpart 2.7, Quality Assurance Requirements for Computer Software for Nuclear Facility
Applications, with implementation guidance published separately in Part IV.

Do spreadsheets count as software?
If a spreadsheet performs a safety-related calculation, yes. Scope is set by consequence, not by the
tool, and spreadsheets are the most commonly overlooked item in the whole programme.

What about commercial software we bought?
Software not produced under a compliant quality assurance programme has to be dedicated under Part II
Subpart 2.14, with critical characteristics identified and verified. Vendor reputation is not
dedication.

Does ISO 9001 or a general software process cover this?
No. Neither reaches the verification, configuration management and records expectations that Subpart
2.7 sets, and neither has any concept of dedication.

How long do software records have to be kept?
Long enough to support the facility, which in practice means decades. Plan retrievability against the
life of the plant rather than the life of the software or the storage medium.

References

• ASME NQA-1 — the standard containing Part II Subpart 2.7.
• NRC Regulatory Guide 1.28, Revision 6 — which NQA-1 editions the NRC endorses, with exceptions.
• DOE — Applying DOE O 414.1C and NQA-1 Requirements to Software.

More on nuclear quality assurance

• NQA-1 software quality assurance — you are here
• NQA-1 and which edition binds you
• 10 CFR 50 Appendix B
• Commercial grade dedication
• The graded approach in NQA-1

All of these are covered by the NQA-1 Toolkit, or start with the free ISO templates.