**Posted 08/09/2005**

**1. Why does the safety software definition include references to 10
CFR 835, DOE P 450.4, and the DEAR ISMS clause?**

The definition for safety software specifies that the software is cited
in a DSA or an approved hazard analysis. 10 CFR 835, DOE P 450.4 and the
DEAR ISMS clause were included to link the "below hazard category 3"
nuclear facilities to a contractor approved hazard analysis.

2\. How were the 10 SQA work activities determined?

Industry consensus standards, DOE rules and directives and other
pertinent documents for software quality assurance, software
engineering, and safety software were reviewed for commonality of
recommended SQA practices. The 10 SQA work activities were found to be
common practices in many of these documents. The documents reviewed
included: ASME NQA-1-2000, IEEE Software Engineering Series, IEEE Std
7-4.3.2, ANS 10.4, NUREG 6263, NASA 8719.13B, RW 0333P, QC-1 Rev 10,
WSRC Manual 20-1 Rev 8, and Pantex Std-1875 Issue 9.

3\. Our site currently does not use NQA-1-2000. Will this be a big
change for our programs?

DOE O 414.1C invokes a generally accepted nuclear industry standard,
NQA-1-2000 or its equivalent. NQA-1-2000 was selected to minimize the
impact on nuclear facilities while ensuring acceptable SQA work
activities are implemented. The SQA10 work activities in the DOE O
414.1C and the associated detail in NQA-1-2000 are consistent with other
industry standards, such as IEEE software engineering series, ISO, IEC,
NASA and ANS. A comparison between the existing site standards and
NQA-1-2000 will identify any gaps. The schedule for closing the gaps
should be determined by the site and its DOE QAP approval authority. EH
support is available to assist in the gap analysis and QAP reviews.

4\. Our site's SQA program is based on 10-CFR-830, ASME NQA-1-2000,
QC-1, RW 0333P, and DOE Orders. Our SQA / QA program and implementing
procedures cover all software. Can we continue to use our grading levels
if they are different from those suggested in the Guide?

DOE O 414.1C requires grading levels to be established, documented and
approved in the QAP. DOE O 414.1C does not specify the number of grading
levels or their criteria. Once the site's QAP complies with DOE O 414.1C
and is approved by DOE the grading levels can be used for safety
software.

5\. Facility design software used by a DOE contractor may be graded
differently than the same software used by a supplier of design services
to the DOE contractor. Why does DOE G 414.1-4 recommend different
grading of the work activities?

There is a difference in grading work activities. The reason has to do
with how much control the DOE contractor has over selecting the facility
design safety software tool. When a DOE contractor uses the software,
the contractor has control over the procurement of the safety software
design tool, acceptance testing of the tool and the training of the
users of the design tool (and some other things). However, if that same
contractor hires a company to perform the design, the DOE contractor is
procuring a \"service\" not a tool. Thus, the contractor may not have
control over the tool being selected. Although DOE G 414.1-4 describes a
different graded approach in this instance, the flow down of
requirements of DOE O 414.1C and 10 CFR 830 must be met.

6\. The Order is silent on software quality requirements for
\"non-safety software\".  What software quality standards are required
for \"non-safety software\"?

DOE O 414.1C and ten QA Criterion applies to all software. However, the
Order does not invoke a specific standard or include SQA requirements
for non-safety software. Thus the requirements specific to safety
software in the Order do not apply. The safety software requirements are
based upon generally accepted and implemented SQA practices in industry
and could be applied to non-safety software.

7\. How do the safety software requirements in DOE O 414.1C apply to DOE
weapons related work?

Since weapons related work is performed in many of DOE's nuclear
facilities, the software that performs a safety function; software that
is used to classify, design, or analyze nuclear facilities; or software
that performs a hazard control function in support of a nuclear facility
falls under the DOE 414.1C safety software requirements. In some
instances software for weapons related activities is also used in the
hazard analysis of a facility. This software may also be defined as
safety software. Naturally the specific instance of use for this
software needs to be investigated to properly determine if the software
in question is considered safety software. This determination will be
performed by the site, the field offices, and the PSO. If determined to
be safety software, the software should be included in the site's safety
software inventory.

8\. How do the safety software requirements in DOE O 414.1C differ from
those in QC-1?

The requirements are consistent and complementary. Both require a
risk-based graded approach for SQA work activities, the flow down of
requirements, and the use of consensus standards. However QC-1 does not
specifically identify software safety design. Some work activities
specifically identified in DOE O 414.1C are addressed in non-software
specific sections of QC-1. An example is training in QC-1 Section 3.2.

9\. Are there any changes in the way software users will be contacted on
software bugs or major issues, especially with respect to software used
by many contractors?

Problem reporting and corrective action is one of the 10 SQA work
activities. DOE and its contractors have the responsibility to report
any defects and major issues to the users of their software. EH
proactively monitors issues with the tool box codes and shares issues
related to these codes or other software of interest to DOE facilities.
EH shares this information through the SQA Knowledge Portal and the
Centreg distribution list, as well as other communications methods.

10\. Is there a centralize list of safety analysis software used by DOE
contractors?

There is no centralized listed of safety software across DOE. DOE 414.1C
requires an inventory list of safety software to be maintained. In 2002,
a survey of safety analysis codes was performed and a report, *Selection
of Computer Codes for US DOE Safety Analysis Applications* is available
on the SQA Knowledge Portal. SQA Knowledge Portal also provides Lessons
Learned and an interactive discussion forum for sharing of information.

11\. How does the graded approach apply to safety software? Can you
provide examples?

The use of safety software has varying levels of impact on the
environment, and the health and safety of the workers and the public.
This impact should be used to develop a graded approach that is
documented and approved in a QAP. The graded approach is then used to
apply the applicable SQA work activities with the appropriate level of
rigor. Safety software at a higher grade level would most likely require
more formal implementation of the SQA work activities than safety
software at a lower grade level. DOE G 414.1-4 provides an acceptable
graded approach that meets DOE O 414.1C requirements. The Guide also
includes specific sub-activities for each of the 10 SQA work activities
and identifies which of these sub-activities should be performed for
each grade level. Examples will be posted on SQA Knowledge Portal.

12\. Can a developer or contractor submit software to DOE to be
considered a toolbox code and included in the Central Registry?

Yes. The procedures to add, revise, or remove software to the Central
Registry is documented in DOE G 414.1-4 Appendix B.

13\. When will the contractor be required to comply with DOE O 414.1C?

By September 17, 2005, actions necessary to implement the requirements
of the Order must be determined by the DOE/NNSA PSOs. The PSOs will
define the contractor compliance date.

**Posted 08/19/2005**

14\. DOE G 414.1-4 section 5.2.7 *Software Safety* identifies guidance
in the area of Risk Management, specifically that during the initial
concept and requirement analysis phases for the software, potential
failures should be identified and evaluated for their consequences of
failure and probability of occurrence. Guidance is provided for the
evaluation for the consequences of failure, however, no guidance is
provided for the probability of occurrence. What is the expectation for
performing a probability of occurrence evaluation? If a probability of
occurrence is to be determined, does DOE have any information i.e. data
on the mean time to failure, of various software applications and the
environments in which the application failed?

Typically software probability of occurrence is performed using relative
scale that is qualitative (frequent, probable, occasional, remote,
improbable[^1]) rather than quantitative scales as done with hardware.
This is one of the areas that make software failures difficult to
predict. DoD comes to mind as good source for the approach to
probability of occurrence. Mean time to failure is one of the best
choices to use. It usually can only be calculated on the system as it is
in operation. Thus an organization collects the data themselves and then
looks at the trends.

15\. DOE G 414.1-4 section 5.2.8 *Verification and Validation*
identifies guidance for Level A software that "continual monitoring of
safety software operations based upon historical failure data...should
be performed". What is the expectation for obtaining the historical
failure data? Is this data to be gathered over time during future
operation, or is it expected that contractors currently have failure
data? Or, is DOE aware of a source for operational failure data for
Level A software?

Historical failure data for software is usually gathered over time by
operations. Even if software is used by multiple organizations the data
does not seem to be shared by that organization and rarely by any
vendor.

16\. What other standards were reviewed for comparison as to which was
the most appropriate for Safety SQA along with NQA-1?

DOE/EH conducted a
[review](http://www.eh.doe.gov/sqa/directives/SQA STANDARDS REPORT 9-30-03.pdf)
of SQA standards as part of the [Software Quality Assurance
Implementation
Plan](http://www.deprep.org/2003/AttachedFile/tb03m13a_enc.doc) (SQA IP)
to determine those standards that would be appropriate for the
Department and its contractors. A working paper, *Quality Assurance
Standards for Safety Software in Department of Energy Nuclear
Facilities*, was issued in September 2003. The standards in this review
included: IAEA Technical Report Series #397; IEC 880, 987 and 1226; ISO
9000-3; DoD 5000.61; NASA 2201-93; ANSI/ASQC E4-1994; and DOE/RW-0333P.
Additionally other consensus standards including the IEEE Software
Engineering Series, IEEE Std 7-4.3.2, ANS 10.4, NUREG 6263, NASA
8719.13B and QC-1 Rev 10 was reviewed during the development of the
Order.

17\. Why does the Order state that 10 CFR 830.120 includes radiological
facilities when it doesn\'t state that?

The Order is correct in including radiological facilities. 10 CFR 830
states the scope for the QA requirements is: "*This subpart establishes
quality assurance requirements for contractors conducting activities,
including providing items or services, that affect, or may affect,
nuclear safety of DOE nuclear facilities*." The Rule further defines
nuclear facility to include non-reactor facility and non-reactor
facility means " ...*those facilities, activities, or operations that
involve, or will involve, radioactive and/or fissionable materials in
such from and quantity that a nuclear or nuclear explosive hazard
potentially exists to workers, the public, or the environment...*". This
inclusion of radioactive facilities is further clarified in EGS 99-01,
*Enforcement of 10 CFR Part 830.120 (Quality Assurance Rule) for
Facilities Below Hazard Category III,* dated 07/01/99.

 

18\. Why does the Order state that we are to use national and
international standard when the Rule (10 CFR 830) requires us to use
voluntary consensus standards? 10 CFR 830 requires the use of voluntary
consensus standards and in the Order this was changed that to make them
additional standards.

10 CFR 830.121(c) (3) requires the use of standards in development and
implementation of the QAP where practicable and consistent with
contractual and regulatory requirements.  This requirement is carried to
the Order in Section 4.a.(2). The Order in 4.a.(3), further establishes
that additional standards, where practicable and consistent with
contractual or regulatory requirements and as necessary to address
unique/specific work activities are to be applied. 

The note in 4.a.(3) clarifies this further. "These standards are
sometimes referred to as "voluntary standards." However, once a
practicable standard(s) is adopted through regulation, code, contract,
QAP, or procedure, compliance with the standard is required and is not
voluntary."

19\. I agree with your conclusion in the *Safety Related Design Software
Survey and Recommendations*, March 2004, report that \"existing software
quality assurance for the safety related design codes is adequate\", but
I do not see where this position has been incorporated into the Guide.
In fact it is very difficult to determine where this type of software is
even addressed in the Guide. Did the team writing the Guide review your
conclusions and recommendations concerning this type of software and
then decide not to incorporate them?

The report's objective was to perform a survey of design codes currently
used across DOE and not to identify or establish requirements for safety
software. Neither the survey nor the report processes were intended to
be an assessment or evaluation of the SQA for any of the design codes in
the survey. The survey and the report referenced were completed prior to
beginning work on the DOE G 414.1-4. Gap analyses of the design code SQA
practices against the criteria in DOE O 414.1C were not performed. If
the gap analyses or an assessment of a particular design code were to be
performed against the criteria/requirements in DOE O 414.1C, the results
may indicate the SQA for that particular design code is adequate.

As with any safety software, the Guide does not assume the quality of
any software is adequate but provides guidance for performing the work
activities to achieve the appropriate level of quality. The Guide does
discuss the Central Registry in Section 3.3.1 and also mentions that
design code tools could be added to the Central Registry. The Guide goes
further to also mention that the safety analysis tool box codes "are not
different from other custom developed safety software as defined in
Section 2.1. Consequently, software of this category \[tool box codes\]
should be developed or acquired, maintained, and controlled applying
sound software practices as described in Section 5 of this Guide."

The Guide did take into consideration the conclusions of the survey
results. Individuals involved in the design code survey were also
writing team members for the safety software Guide. From the description
of the software and its use as stated above, it appears the software
mentioned would fall into the category identified as acquired safety and
hazard analysis and design software in the DOE G 414.1-4. Section 2.1 of
the Guide identifies and describes acquired software. The analysis of
the software's impact on safety would determine the grading level for
the acquired design software. DOE G 414.1-4 then provides a graded
approach and identifies the specific work activities and sub activities
to be applied for this software type and grade level.

20\. Would it be possible to establish a second \"Tool Box\" that
addresses this type of software \[design codes\] based upon your
analysis that typically the design software have been in place for years
with multiple users and a vested interest by the developer to maintain
the quality of the software?

As mentioned above, EH through the establishment of the Central Registry
and DOE G 414.1-4 Appendix B procedures have allowed for the addition of
design codes to the Central Registry. If a design code meets the
criteria for inclusion into the Central Registry DOE would consider
adding it as a tool box code. Please refer to Appendix B for the
criteria and procedures.

21\. Would it be possible to add a new definition to the Order and the
Guide that specifically addresses this type of software \[design codes\]
and not assume it is covered by one of the other definitions since this
type of software is somewhat unique as you pointed out in your report?

 

Safety software design codes are adequately addressed by the definition
for safety and hazard analysis and design software. That definition is:
Software that is used to classify, design, or analyze nuclear
facilities.  This software is not part of a structure, system, or
component (SSC) but helps to ensure the proper accident or hazards
analysis of nuclear facilities or an SSC that performs a safety
function.

**Posted 12/19/2005**

22\. Please clarify the response to FAQ #7 \[regarding DOE O 414.1C
safety software requirements applicability to DOE weapons related
work\]. If the \[weapon related\] software is not included in a nuclear
facility (i.e., performs a safety function; is used to classify, design,
or analyze nuclear facilities; or performs a hazard control function in
support of a nuclear facility) is it considered safety software?

The safety software definitions include software may not be included in
a nuclear facility but that supports the nuclear facility. Thus some
safety software may reside and be used in other locations outside the
nuclear facility. Safety and Hazard Analysis Software and Design
Software will not reside within the facility. There may be instances
where the same software used for weapons related work is also used for
safety or hazard analysis decisions. In these instances, the software
needs to be investigated to determine the software meets the safety
software definition.

23\. If a site is using one of the toolbox codes, is it correct to
assume that we can expect error free results?

It is difficult, and in most instances impossible, to assure error free
results with any software application. Exhaustive testing to ensure
error free results is not possible with most software. Many of the tool
box codes are moderate to complex in logic, structure and functionality.
Since each user of the software and the user's application of the
software may exercise a different path through the software that has not
been tested, it is impossible ensure error free results. However, the
Central Registry toolbox codes were evaluated based upon SQA criteria
consistent with the requirements in DOE O 414.1C. This evaluation
identified the gaps in the software quality assurance work activities.
Additionally a guidance report was issued for the use of each tool box
code. The intent of the gap analysis and guidance report was to provide
a level of confidence in using the tool box codes (within the
limitations and guidance noted).

24\. Yucca Mountain is regulated by the NRC and NQA-1-1983 is the latest
version that is endorsed (see NUREG 1804). DOE O 414.1A had an
exclusion. DOE O 414.1B appears to have removed that exclusion and the
exclusion is still removed in DOE O 414.1C. There is a problem working
to the Order and NRC. Does DOE O 414.1C provide exclusion in this area?

The QA Order states, "Where a work activity, process or item is
specifically identified as within the scope of a QA regulation (e.g. 10
CFR 830 or 10 CFR 63), that regulation prevails. In the event of a
conflict between this Order and any QA regulation, the regulation
prevails". Thus the Order allows for regulated work to be excluded from
the specific DOE O 414.1C requirements. The Applicability section (3a
paragraph 2) in the Order includes a requirement to integrate multiple
QAP drivers imposed by QA regulations, the NRC, the EPA and other
Federal agencies. This integration requirement supplements but does not
supersede or alter compliance with any QA regulations. The combined
intent of these statements is to ensure all work is conducted under
either a DOE QAP or a QAP approved by the external regulator. It should
also be noted that the NRC guidance for 10 CFR 63 (QA rule for the Yucca
Mountain Project), as identified in NUREG 1804 (the Yucca Mountain
Review Plan), also endorses NQA-1-2000 for software important to safety.

25\. The Contractor Requirements Document (CRD) in Attachment 2 of the
Order states: "The contractor must consider QA guidance in developing
and implementing a QAP. The following guidance documents ..." During an
assessment, what evidence is expected to be produced to adequately
demonstrate that the QA guidance was considered but not used in the
development or implementation of a QAP?

As noted in DOE G 414.1-4 alternative methods to those described in the
Guide may be used provided they result in compliance with the
requirements of 10 CFR 830 Subpart A and DOE O 414.1C. The evidence to
demonstrate that a contractor consider the use of DOE G 414.1-4 will be
determined by the DOE approval authority for the QAP. An assessment team
should typically review the evidence as specified by the QAP approval
authority. Evidence may be as simple as a statement in the approved QAP
that the DOE G 414.1-4 was reviewed and considered in its development.

26\. The safety software definitions in the issued DOE O 414.1C were
modified from the SQAIP definitions. These changes appear to expand the
scope of safety software. Can you explain the new scope and why the
definitions were expanded?

During the drafting and comment resolution process for DOE O 414.1C the
definitions in the SQAIP were thoroughly analyzed to determine if the
scope of safety software captures the control of all hazards presented
by DOE nuclear facilities. Key terms in these definitions were reviewed.
It was observed through conversations and early implementation of the
SQAIP, that the definitions in the SQAIP resulted in varying
interpretation and thus varying implementation. To reduce this
variability and to resolve several major comments, the safety software
definitions were modified to use and reference key terms from 10 CFR 830
and to tighten the interpretation of the safety software definitions. A
matrix of the SQAIP definitions, the DOE O 414.1C definitions, and the
detail basis for the changes is available should more detail be desired.

27\. The SQA section of the order references the \'DEAR ISMS Clause\'. 
Can you specify exactly which DEAR clause you are referring to?

The DEAR ISMS clause \[48 CFR 970.5223-1\].

28\. Our contractor has implemented the *Quality Assurance Requirements
and Description* (DOE-RW-0333P) for NRC regulated work (Yucca Mountain
Project) under 10 CFR 63. DOE-RW-0333P includes requirements for
software quality. DOE G 414.1-4, Appendix D, references the DOE - RW-
0333P document. By this reference, can we assume that this document
\[DOE-RW-0333P\] is a DOE-approved alternate standard for use as an
equivalent to ASME NQA-1-2000? Secondly, does this reference imply DOE
-RW-0333P meets all of the safety software quality requirements in DOE O
414.1C?

The DOE G 414.1-4 Appendix D reference to DOE-RW-0333P is not an
endorsement of that document as an alternative equivalent to NQA-1-2000.
The NRC evaluates DOE-RW-0333P for acceptability for work regulated
under 10 CFR 63. This NRC regulated work is exempt from DOE O 414.1C.
Since DOE-RW-0333P responds to a different set of regulatory
requirements, it naturally does not include every safety software QA
requirement found in DOE O 414.1C. Therefore, as Appendix D states,
DOE-RW-0333P should be evaluated to determine its equivalency to O
414.1C and ASME NQA-1-2000 for the 10 work activities identified in DOE
O 414.1C. The DOE organization that intends to apply DOE-RW-0333P has
the responsibility to perform this evaluation and document the
equivalency.

29\. Some external regulators, standards bodies, or industries classify
safety software as software that if fails will kill or seriously injury
humans. Consequently, they may only specify one method (no grading) to
build the software or apply QA requirements. Does the DOE graded
approach and broader definition of safety software depart from the
customary and prudent practices in the field of software engineering?

If DOE Safety Software is developed with a graded approach and used by
DoD, NRC or DHS, could this result in the death or serous injury of a
human?

The term "safety software" in DOE O 414.1C is defined for specific
hazards and uses within DOE. The Order is compatible with 10 CFR 830 and
DOE nuclear safety directives. While the Order does not use the same
definition as other standards or industry documents noted in the
question, DOE O 414.1C does define safety software through three
different safety software types (safety system software, safety and
hazard analysis software and design software, and safety management and
administrative controls software). These three different types and their
use may have different levels of impact on health or safety of the
worker, public or the environment. Thus grading is appropriate for DOE
nuclear facility safety applications.

DOE O 414.1C safety software requirements and 10 CFR 830 regulations do
not apply where other agencies (e.g., NRC or EPA) requirements are
applicable. For other safety software that might be developed under a
work-for-others or other contractual agreements, if more or less
rigorous safety software quality assurance criteria is required than
those of DOE O 414.1C, the work activities for project management and
quality planning, software requirement identification and management,
and procurement should identify the more rigorous software quality
assurance standards. The implementation of the appropriate DOE safety
software 10 work activities should ensure the software is developed
according to any contractual agreements and to the safety software
requirements.

**Posted 06/13/2006**

**30. In reading the Guide for 414.1C, in Appendix E. Safety Software
Analysis and Management Process, the 1st part of the process (everything
above the dotted line, is stated as it must be done per DOE STD 3009-94
and must be documented per DOE STD 3009-94 and DOE STD 3011-94. In
searching through DOE O 414.1C, this requirement does not exist. It
appears the Guide is adding requirements that do not exist in the Order.
Is the Guide adding requirements?**

The DOE G 414.1-4 Appendix E describes the process for determining if
safety software is associated with the nuclear facility. The references
to DOE-Std 3009-94 and DOE-Std 3011-94 are to indicate their association
with safety software. In the next update of the Guide, Appendix E will
be reviewed to clarify the intent of the diagram.

**31.** **In SQA assessments conducted at our site, one of the lessons
learned that always arises is the CRAD (which came from the DNFSB
Recommendation 2002-1, the draft safety software guide, the DOE Order
414.1 and now from the new guide and DOE Order 414.1C) we use for either
COTS or developed software SQA assessments contains criteria that may or
may not apply depending on the type of software. Sometimes it doesn\'t
make any sense to use the CRAD because it does not apply and may be
confusing. Do you know if these CRADS will be revised so that it will
clearly state which one is applicable to either developed software or
COTS?**

The CRAD, <http://www.2004-1.org/commitments/5/docs/new/sqa.htm>, has
been updated as part the of the DOE Oversight Manual (DOE M 226.1)
effort. The criteria in the CRAD apply to all safety software
irregardless of the safety software definition or software type
(acquired or custom). The Lines of Inquiry associated with the CRAD
should be customized to fit the DOE approved graded approach and ASME
NQA-1-2000 or a standard with an equivalent level of SQA requirements
approved by DOE. Since the graded approach and standard(s) approved can
vary from site-to-site, there is no single set of Lines of Inquiry that
could be developed that would be applicable to all sites. The Lines of
Inquiry included with the CRAD
<http://www.2004-1.org/commitments/5/docs/new/sqa.htm>, associated with
the DOE Oversight Manual are based upon the graded approach in DOE G
414.1-4 and ASME NQA-1-2000. Those Lines of Inquiry attempt to address
the graded approach in the DOE safety software guide. These Lines of
Inquiry could be improved to specifically address the software type
(acquired or custom). We will note this omission and hope to include the
improvement in a future release of the Lines of Inquiry. In the interim,
for sites using the graded approach in the DOE safety software guide and
the Lines of Inquiry associated with the DOE Oversight Manual CRAD,
Section 5 of the DOE safety software guide should provide the needed
information to customize the Lines of Inquiry.

**32. Is safety software limited to software that if it functions
incorrectly may result in radiological hazards?**

No. All software that is associated with hazards (radiological or
non-radiological) in a nuclear facility may fall within the definition
of safety software. The 3 definitions of safety software focus on the
function of the software not the impact of software failure. The impact
of software malfunctioning is addressed by software safety and risk
management approaches. The impact of the safety software malfunctioning
should be used with the graded approach to determine how the 10 safety
software work activities are implemented, but it is not intended to
limit the application of the requirements or be the sole factor for
identifying safety software.

**33. Hazard has not been defined in DOE O 414.1C, but Hazard Controls
has been defined. Does the definition of Hazard Controls include hazards
other than radiological?**

Yes. Software used to mitigate a hazard by providing hazard controls in
a nuclear facility is considered safety software. Those hazards may not
all be radiological. The safety software definition is also bounded by
the term *nuclear facility*. Thus the hazard (whether radiological or
not) and its controls will be associated with a nuclear facility. This
software may fall into [all]{.underline} 3 categories of the safety
software definition.

Hazard is defined in 10 CFR 830 as "a source of danger (i.e., material,
energy source, or operation) with the potential to cause illness,
injury, or death to a person or damage to a facility or to the
environment (without regard to the likelihood or credibility of accident
scenarios or consequence mitigation)."

Hazard controls is defined in 10 CFR 830 as "measures to eliminate,
limit, or mitigate hazards to workers, the public, or the environment,
including:

> \(1\) Physical, design, structural, and engineering features;
>
> \(2\) Safety structures, systems, and components;

\(3\) Safety management programs;

\(4\) Technical safety requirements; and

\(5\) Other controls necessary to provide adequate protection from
hazards.

**34. Is it required for any type of safety software to be cited in an
approved safety analysis** **for the nuclear facility?**

No, it is not required*.* If the safety basis depends on the safety
software, and it is implemented through plans, procedures, safety
documents, etc. the safety software would be implicitly part of the
safety basis. For example, a change to the software that is invoked by
operational procedures would be subject to the unreviewed safety
question (USQ) process.

[^1]: From DoD 882E