September 1997 U.S. NUCLEAR REGULATORY COMMISSION

REGULATORY GU 

OFFICE OF NUCLEAR REGULATORY RESEARCH 

REGULATORY GUIDE 1.172 

(Draft was DG-1058) 

SOFTWARE REQUIREMENTS SPECIFICATIONS FOR 

DIGITAL COMPUTER SOFTWARE USED IN SAFETY SYSTEMS 

OF NUCLEAR POWER PLANTS

A. INTRODUCTION 

In 10 CFR Part 50, "Domestic licensing of Pro

duction and Utilization Facilities," paragraph 55a(a)(1) 

requires, in part, 1 that systems and components be de

signed, tested, and inspected to quality standards com

mensurate with the safety function to be performed. 

Criterion 1, "Quality Standards and Records," of Ap

pendix A, "General Design Criteria for Nuclear Power 

Plants," to 10 CFR Part 50 requires, in part, 1 that 

appropriate records of the design and testing of systems 

// and components important to safety be maintained by 

or under control of the nuclear power unit licensee 

throughout the life of the unit. Appendix B, "Quality 

Assurance Criteria for Nuclear Power Plants and Fuel 

Reprocessing Plants," to 10 CFR Part 50 describes cri

teria that a quality assurance program for systems and 

components that prevent or mitigate the consequences 

of postulated accidents must meet. In particular, 

besides the systems and components that directly pre

vent or mitigate the consequences of postulated acci

dents, the criteria of Appendix B also apply to all activi

ties affecting the safety-related functions of such 

systems and components as designing, purchasing, 

t

in this regulatory guide, many of the regulations have been paraphrased; 

see 10 CFR Part 50 for the full text.

IDE

installing, testing, operating, maintaining, or modify

ing. A specific requirement is contained in 10 CFR 

50.55a(h), which requires that reactor protection sys

tems satisfy the criteria of IEEE Std 279-1971, "Crite

ria for Protection Systems for Nuclear Power Genera

ting Stations." 2 Paragraph 4.3 of IEEE Std 279-19713 

states that quality of components is to be achieved 

through the specification of requirements known to 

promote high quality, such as requirements for design, 

inspection, and test. 

Several of the General Design Criteria (GDC) of 

Appendix A, including Criteria 12, 13, 19, 20, 22, 23, 

24, 25, and 28, describe functions that are part of the de

sign bases of nuclear power plants and that would be in

cluded in the software requirements specification 

(SRS) of any digital computer software that is part of 

basic components that perform these functions. In addi

tion to the criteria of Appendix A, Appendix B to 

10 CFR Part 50 provides quality assurance criteria that 

2Revision I of Regulatory Guide 1.153, "Criteria for Safety Systems," en

dorses IEEE Std 603-1991,"Criteria for Safety Systems for Nuclear Pow

er Generating Stations," as a method acceptable to the NRC staff for satis

fying the NRC's regulations with respect to the design, reliability, qualifi

cation, and testability of the power, instrumentation, and control portions 

of the safety systems of nuclear power plants. 

31EEE publications may be obtained from the IEEE Service Center, 445 

Hoes Lane, Piscataway, NJ 08854.

USNRC REGULATORY GUIDES The guides are lesued In the following ton broad divisions: 

Regulatory Guides awe itsued to describe and make a"ailable to the public such i*rma

lion as methods acceptable to the NRC stff or implementing specific partsof ftCom- 1. PooerReactors 6. Products 

In*on5s regulations, tscmques used bythestaff evaluating specific problems or ps- 2. Research aid Test Reactors 7. Transportation 

lulated accidents, end data needed by the NRC Iitafflis review of applitio for Per . Fuets and Materials Facilities 8. Occupational Health 

mits and licenses. Regulatory guides n stus lor egiitori, n compilan. e 4. FJMrontentald. anarFcini Review 

with them Is not raqtird. MeZthods ando beons differe hosa OUtheg 5o. 5 Matedals and Plant Protection 10 General 

wi be acceptable If they provide a basis for the findings requisite to the issuance or con

Inuence of a permit or license by the Commission. Single copies of regulatory guides may be obtained k of charge bywing the Printing, 

Ths guLide was Issued after consideration of comments receved from the publc. Com- Graphics ard Disaibuton Brnch, O1ce ofAdministrallon, U.S. Nular eguatory 

mentsandsuggestions forimproveme Intiheseguldes wemecouraged atall tlhs, ad mission, Washington, DC 20555-0001; or by fax at (301)415-5272. 

es will be revised. es appropriate, to accommodste comments and to reflect new in

= on r oerlece.issued guides may also be purchased from the National Techiwical Information Service on 

Written comments may be aubmitted to the Rues Review mid Directives Branch, DFIPS, a standing order basis. Detalls on this service may beIobtained by writingN• S, 5285 Port 

ADM, U.S. Nuclear Regulatory Comnmissicn, Washington, DC 20555-0001. Royal Road, Springfield. VA22161.
design documentation for nuclear reactor safety sys

tems must meet. Criterion III, "Design Control," 

requires measures for design documentation and identi

fication and control of design interfaces, as well as 

measures for verifying or checking the adequacy of the 

design. 

This regulatory guide endorses IEEE Std 

830-1993, "IEEE Recommended Practice for Software 

Requirements Specifications,"'3 with the exceptions 

stated in the Regulatory Position. IEEE Std 830-1993 

describes a method acceptable to the NRC staff for 

complying with the NRC's regulations for achieving 

high functional reliability and design quality in soft

ware used in safety systems. 4 In particular, the method 

is consistent with GDC 1 and the criteria for quality as

surance programs in Appendix B as they apply to the 

development of software requirements specifications. 

The criteria of Appendices A and B apply to systems 

and related quality assurance processes, and if those 

systems include software, the requirements extend to 

the software elements. 

In general, information provided by regulatory 

guides is reflected in the Standard Review Plan 

(NUREG-0800), which is used by the Office of Nu

clear Reactor Regulation in the review of applications 

to construct and operate nuclear power plants. This reg

ulatory guide will apply to the revised Chapter 7 of that 

document. 

The information collections contained in this regu

latory guide are covered by the requirements of 10 CFR 

Part 50, which were approved by the Office of Manage

ment and Budget, approval number 3150-0011. The 

NRC may not conduct or sponsor, and a person is not 

required to respond to, a collection of information un

less it displays a currently valid OMB control number. 

B. DISCUSSION 

The use of industry consensus standards is part of 

an overall approach to meeting the requirements of 

10 CFR Part 50 when developing safety systems for 

nuclear power plants. Compliance with standards does 

not guarantee that regulatory requirements will be met. 

However, compliance does ensure that practices ac

cepted within various technical communities will be in

corporated into the development and quality assurance 

4The term "safety systems" is synonymous with "safety-related systems." 

The General Design Criteria cover systems, structures, and components "important to safety." The scope of this regulatory guide is, however, lim

ited to "safety systems," which are a subset of "systems important to 

safety."

processes used to design safety systems. These prac

tices are based on past experience and represent indus

try consensus on approaches used for development of 

such systems. 

Software incorporated into instrumentation and 

control systems covered by Appendix B will be referred 

to in this regulatory guide as safety system software. 

The software requirements specification is an essential 

part of the record of the design of safety system soft

ware. Associated with system requirements allocated 

to software subsystems, software requirements serve as 

the design bases for the software to be developed. 

Therefore, software requirements specifications are a 

crucial design input to the remainder of the software 

development process. Software requirements specifi

cations should exhibit characteristics, such as correct

ness and completeness, that will facilitate the imple

mentation of a carefully planned and controlled 

software development process. 

One consensus standard on software engineering, 

IEEE Std 830-1993, describes current practice for writ

ing software requirements specifications for a wide 

variety of systems. It is not specifically aimed at safety 

applications; however, it does provide guidance on the 

development of software requirements specifications 

that will exhibit characteristics important for develop

ing safety system software. This is consistent with the 

NRC staff's goals of ensuring high-integrity software 

in reactor safety systems. 

Other standards mention software requirements 

specifications but do not provide detailed guidance for 

writing them. IEEE Std 7-4.3.2-1993, "Standard Cri

teria for Digital Computers in Safety Systems of Nu

clear Power Generating Stations,",3 which is endorsed 

by Revision 1 of Regulatory Guide 1.152, "Criteria for 

Digital Computers in Safety Systems of Nuclear Power 

Plants," mentions unambiguous software requirements 

as a prerequisite for high quality software develop

ment. IEEE Std 1012-1986, "IEEE Standard for Soft

ware Verification and Validation Plans," 3 mentions un

ambiguous software requirements as a prerequisite for 

verification and validation. IEEE Std 1074-1991, 

"IEEE Standard for Developing Software life Cycle 

Processes," 3 describes software requirements specifi

cations as an essential input at the beginning of a soft

ware development life cycle. Correct, complete, well

written and unambiguous software requirements are 

essential inputs to the main design and verification pro

cesses that are accepted as necessary to produce high

integrity software products [see NUREG/CR-6101, 

"Software Reliability and Safety in Nuclear Reactor

1.172-2
Protection Systems" (November 1993),5 and NUREG/ 

CR-6263, "High Integrity Software for Nuclear Power 

Plants: Candidate Guidelines, Technical Basis and Re

search Needs" (June 1995)5]. 

C. REGULATORY POSITION 

The recommended practices in IEEE Std 

830-1993 provide an approach that is acceptable to the 

NRC staff for meeting the requirements of 10 CFR Part 

50 as they apply to the preparation of software require

ments specifications for safety system software, sub

ject to the exceptions listed below. 

To meet the requirements of 10 CFR 50.55a(h) and 

Appendix A to 10 CFR Part 50 as assured by complying 

with the criteria of Appendix B applied to the verifica

tion, validation, reviews, and audits of software used in 

or affecting basic components of nuclear power plants, 

the following exceptions are necessary and will be con

sidered by the NRC staff in the review of submittals 

from applicants and licensees. (In this Regulatory Posi

tion, the cited criteria are in Appendix A or B of 10 CFR 

Part 50 unless otherwise noted.) 

1. DEFINITIONS 

Section 3 of IEEE Std 830-1993 refers to IEEE 

Std 610.12-1990, "IEEE Standard Glossary of Soft

ware Engineering Terminology," 3 for definitions of 

technical terms. These definitions are acceptable with 

the following clarifications or additions. 

1.1 Baseline 

Meaning 1 of baseline in IEEE Std 610.12-1990 is 

to be used in IEEE Std 830-1993. Formal review and 

agreement is taken to mean that responsible manage

ment has reviewed and approved a baseline. 

1.2 Interface 

All four variations of meaning in IEEE 

610.12-1990 are to be used in IEEE Std 830-1993, de

pending on the context. Meaning 1, "A shared bound

ary across which information is passed," is interpreted 

broadly according to Criterion III to include design in

terfaces between participating design organizations. 

5

Copies are available at current rates from the U.S. Government Printing 

Office, P.O. Box 37082, Washington, DC 20402-9328 (telephone 

(202)512-2249); or from the National Technical Information Service by 

writing NTIS at 5285 Port Royal Road, Springfield, VA 22161. Copies are 

available for inspection or copying for a fee from the NRC Public Docu

ment Room at 2120 L Street NW., Washington, DC; the PDR's mailing ad

dress is Mail Stop LL-6, Washington, DC 20555-0001; telephone 

(202)634-3273; fax (202)634-3343.

2. SOFTWARE REQUIREMENTS 

SPECIFICATIONS 

Section 4.3 of IEEE Std 830-1993 defines a set of 

characteristics of a good software requirements specifi

cation (SRS). The first sentence of this section should 

be modified to read "An SRS must be...." The follow

ing clarifications and additional information should be 

provided for this set of characteristics for safety system 

software. 

2.1 Traceability and Accuracy 

When specification or representation tools are used 

for requirements, as described in sections 4.3.2.2 and 

4.3.2.3 of IEEE Std 830-1993, traceability should be 

maintained between these representations and the natu

ral language descriptions of the software requirements 

that are derived from system requirements and system 

safety analyses. 

2.2 Completeness 

For safety system software, the description of func

tional requirements should specify how functions are 

initiated and terminated as well as the system status at 

termination. Accuracy requirements, including units, 

error bounds, data type, and data size, should be pro

vided for each input and output variable. Variables con

trolled or monitored in the physical environment 

should be fully described. Functions expressly prohib

ited should also be described. 

Timing information is particularly important in 

specifying software requirements for safety system 

software. Functions with timing constraints should be 

identified and criteria for each mode of operation 

should be provided. Timing requirements should be de

terministic and specified for both normal and antici

pated failure conditions. 

2.3 Consistency 

IEEE Std 830-1993 restricts the term to mean in

ternal consistency, noting that an external 

inconsistency is actually an incorrect specification of a 

requirement. The term is used in this regulatory guide 

to mean both internal and external consistency. Exter

nal consistency implies that the SRS is consistent with 

associated software products and system products, 

such as safety system requirements and design. Internal 

consistency means that no requirement in the require

ments specification conflicts with any other require

ment in the specification. 

2.4 Ranking for Importance or Stability 

For safety system software, this characteristic 

means that software requirements important to safety 

must be identified as such in the SRS. Criterion 20 of

1.172-3
Appendix A, among others, describes the functions that 

reactor protection systems must perform. Section 

4.3.5.2 of IEEE Std 830-1993 suggests three degrees of 

necessity of requirement: essential, conditional; and 

optional. As used in IEEE Std 830-1993, the terms 

conditional and optional refer to requirements that are 

not necessary for the software to be acceptable. For 

safety system software, unnecessary requirements 

should not be imposed. There may be documented vari

ations in essential requirements, but the variations must 

be linked in the software requirements specifications 

either to site and equipment variations or to specific plant design bases and regulatory provisions. 

2.5 Verifiability 

IEEE Std 830-1993 recommends the removal or 

revision of unverifiable requirements. This is clarified 

to mean that all requirements should be verifiable and 

should be modified or restated as necessary so that it is 

possible to verify each one. 

2.6 Modifiability 

This term is closely related to the style (form, struc

ture, and modularity), readability, and understandabil

ity of the SRS. With respect to these characteristics, it is 

important that precise definitions of technical terms be 

available, either in the SRS or in a glossary. 

2.7 Traceability 

Section 4.3.8 of IEEE Std 830-1993 describes two 

types of traceability, and both types are required. Each 

identifiable requirement in an SRS must be traceable 

backwards to the system requirements and the design bases or regulatory requirements that it satisfies. Each 

identifiable requirement should be written so that it is 

also "forward traceable" to subsequent design outputs, 

e.g., from SRS to software design and from software 

design to SRS. 

Forward traceability to all documents spawned by the SRS includes verification and validation materials. 

For example, a forward trace should exist from each re

quirement in the SRS to the specific inspections, analy

ses, or tests used to confirm that the requirement has 

been met. 

3. CHANGE CONTROL IN SRSs 

Section 4.5(b) of IEEE Std 830-1993 recommends 

that SRSs be baselined and subject to a formal process for control of changes. The SRS must be subject to con

trol of changes. Although this could be met directly by 

a change control procedure unique to IEEE Std 830

1993, it may also be accomplished by taking the SRS

under a general software configuration management 

program as a configuration item. 

4. INCOMPLETE SRS ENTRY 

Any entry in an SRS that is incomplete (uses 

"TBD"), as described by section 4.3.3.1 of IEEE Std 

.830-1993, must describe the applicable design bases 

and commitments to standards or regulations that gov

ern the final determination of the requirement entry. 

5. DESIGN-SPECIFIC ISSUES 

Section 4.7 of IEEE Std 830-1993 recommends 

that design-specific issues such as module partition

ing, function allocation, and information flow be 

omitted from SRSs. Section 4.7.1 of IEEE Std 

830-1993 states some exceptions to this policy, includ

ing reasons of security or safety. When specific design 

techniques or features such as independence, separa

tion, diversity, and defense-in-depth are required by the 

safety system design bases or by regulation, these are 

an appropriate part of an SRS and they should be de

scribed therein. 

6. SOFTWARE ATTRIBUTES 

Section 5.3.6 of IEEE Std 830-1993 lists software 

attributes that can serve as requirements. Attributes of 

particular interest for safety system software are safety, 

security, and reliability or robustness. 

6.1 Safety 

Software requirements important to safety are de

rived from system requirements and safety analyses 

and should be identified as such in the SRS. These re

quirements should include considerations based on the 

safety analysis report (SAR) as well as abnormal condi

tions and events (ACEs) as described in IEEE Std 

7-4.3.2-1993, as endorsed by Revision 1 of Regula

tory Guide 1.152. 

6.2 Security 

Security threats to the computer system should be 

identified and classified according to impact on safety 

and likelihood of occurrence. Actions required of the 

software to detect, prevent, or mitigate such security 

threats should be specified, including access control re

strictions. For instance, modification of instrument cal

ibration data might be protected by a password system. 

6.3 Robustness 

Software requirements for fault tolerance and fail

ure modes, derived either from consideration of system 

level hazards analyses or from consideration of soft

ware internals, should be specified for each operating 

mode. Software behavior in the presence of unex

pected, incorrect, anomalous, and improper input,

1.172-4
hardware behavior, or software behavior should be 

fully specified. Software requirements for responding 

to both hardware and software failures should be pro

,/ vided, including requirements for analysis of and re

covery from computer system failures. Requirements 

for on-line in-service testing and diagnostics should be 

specified. 

7. NONAPPLICABILITY 

Because of its generality, IEEE Std 830-1993 dis

cusses or recommends a number of content items that 

may be inappropriate to real-time, embedded safety 

systems. Headings for such inappropriate subjects in an 

SRS that is compliant with IEEE Std 830-1993 should 

be listed, followed by "Not applicable." For example, a 

graphical user interface may be inappropriate for a real

time, embedded reactor trip system. 

-8. APPLICABILITY OF ANNEX A 

Annex Ato IEEE Std 830-1993 is not endorsed by 

this regulatory guide and may be taken only as exam

ples. Directions to use an outline from Annex A, such 

as those directions found in section 5.3.7 of IEEE Std 

830-1993, may be taken as advisory only. 

9. OTHER CODES AND STANDARDS 

Various sections in IEEE Std 830-1993 reference 

several industry codes and standards. These referenced 

standards should be considered individually. If a refer

enced standard has been incorporated separately into

the NRC's regulations, licensees and applicants must 

comply with that standard as set forth in the regulation. 

If the referenced standard has been endorsed in a regula

tory guide, the standard constitutes a method accept

able to the NRC staff of meeting a regulatory require

ment as described in the regulatory guide. If a 

referenced standard has been neither incorporated into 

the NRC's regulations nor endorsed in a regulatory 

guide, licensees and applicants may consider and use 

the information in the referenced standard, if appropri

ately justified, consistent with current regulatory 

practice. 

D. IMPLEMENTATION 

The purpose of this section is to provide informa

tion to applicants and licensees regarding the NRC 

staff's plans for using this regulatory guide. No backfit

ting is intended or approved in connection with the 

issuance of this proposed guide. 

Except in those cases in which an applicant pro

poses an acceptable alternative method for complying 

with the specified portions of the NRC's regulations, 

the methods described in this guide will be used in the 

evaluation of submittals in connection with applica

tions for construction permits and operating licenses. 

This guide will also be used to evaluate submittals from 

operating reactor licensees that propose system modifi

cations voluntarily initiated by the licensee if there is a 

clear connection between the proposed modifications 

and this guidance.

1.172-5
BIBLIOGRAPHY

Hecht, H., A.T. Tai, K.S. Tso, "Class 1E Digital Sys

tems Studies," NUREG/CR-6113, USNRC, October 

1993.1 

Institute of Electrical and Electronics Engineers, "Stan

dard Criteria for Digital Computers in Safety Systems 

of Nuclear Power Generating Stations," IEEE Std 

7-4.3.2, 1993. 

Lawrence, J.D., "Software Reliability and Safety in 

Nuclear Reactor Protection Systems," NUREG/ 

CR-6101 (UCRL-ID-117524, Lawrence Livermore 

National Laboratory), USNRC, November 1993.1 

1Copies may be purchased at current rates from the U.S. Government Prin

ting Office, P.O. Box 37082, Washington, DC 20402-9328 (telephone (202)512-2249); or from the National Technical Information Service by writing NTIS at 5285 Port Royal Road, Springfield, VA 22161. Copies are available for inspection or copying for a fee from the NRC Public Docu

ment Room at 2120 L Street NW., Washington, DC; the PDR's mailing ad

dress is Mail Stop LL-6, Washington, DC 20555-0001; telephone 

(202)634-3273; fax (202)634-3343.

Lawrence, J.D., and G.G. Preckshot, "Design Factors 

for Safety-Critical Software," NUREG/CR-6294, 

USNRC, December 1994.1 

Seth, S., et al., "High Integrity Software for Nuclear 

Power Plants: Candidate Guidelines, Technical Basis 

and Research Needs," NUREG/CR-6263, USNRC, 

June 1995.1 

USNRC, "Criteria for Digital Computers in Safety 

Systems of Nuclear Power Plants," Regulatory Guide 

1.152, Revision 1, January 1996.2 

USNRC, "Standard Review Plan," NUREG-0800, 

February 1984. 

2

Single copies of regulatory guides may be obtained free of charge by writ

ing the Office of Administration, Printing, Graphics and Distribution 

Branch, U.S. Nuclear Regulatory Commission, Washington, DC 

20555-0001; or by fax at (301)415-5272. Copies are available for in

spection or copying for a fee from the NRC Public Document Room at 

2120 L Street NW, Washington, DC; the PDR's mailing address is Mail 

Stop LL-6, Washington, DC 20555-0001; telephone (202)634-3273; fax 

(202)634-3343.

1.172-6
REGULATORY ANALYSIS

A separate regulatory analysis was not prepared for this regulatory guide. The 

regulatory analysis prepared for Draft Regulatory Guide DG-1058, "Software Re

quirements Specifications for Digital Computer Software Used in Safety Systems 

of Nuclear Power Plants," provides the regulatory basis for this guide. A copy of 

the regulatory analysis is available for inspection and copying for a fee at the NRC 

Public Document Room, 2120 L Street NW., Washington, DC; the PDR's mailing 

address is Mail Stop LL-6, Washington, DC 20555-0001; phone (202)634-3273; 

fax (202)634-3343. 

2n 

Federal Recycling Program

1.172-7
UNITED STATES 

NUCLEAR REGULATORY COMMISSION 

WASHINGTON, DC 20555-0001

"I 

FIRST CLASS MAIL 

POSTAGE AND FEES PAID 

USNRC 

PERMIT NO. G-67

OFFICIAL BUSINESS 

PENALTY FOR PRIVATE USE, $300

*0 

co 

C 

0 

w-4 

w 

z 

wi