Document: NRC Regulatory Guide
Document ID: 2980f2d9-2e7d-4afa-9e1f-a8abe5fb7507
Document Type: regulatory_guide
Title: Software Requirement Specifications for Digital Computer Software and Complex Electronics Used in Safety Systems of Nuclear Power Plants + HISTORY - HISTORY 08/2012 – DG-1209 , Proposed Revision 1 08/1996 – DG-1058 , Proposed Revision 0 (Rev. 1)
Source: NRC Regulatory Guide Division 1
Source URL: https://www.nrc.gov/docs/ML1030/ML103080963.pdf
Revision Date: 2023-06
Chapter: 
Section ID: RG-1.172
CFR Part: 
CFR Title: 

Content:
eptable SRS. The first sentence of this clause should be modified to read, “An SRS must be….” The licensee or applicant should provide the following clarifications and additional information for this set of characteristics for safety system software: a. Traceability and Accuracy. When the licensee or applicant uses specifications or representation tools for requirements, as described in Subclauses 4.3.2.2 and 4.3.2.3 of IEEE Std. 830-1998, traceability must be maintained between these representations and the natural language descriptions of the software requirements that are derived from system requirements and system safety analyses to meet the requirements in GDC 1 of Appendix A to 10 CFR Part 50. b. Completeness. For safety system software, the description of functional requirements should specify how functions are initiated and terminated and should specify the system status at termination. The licensee or applicant should provide the accuracy requirements, including units, error bounds, data type, and data size, for each input and output variable. The licensee or applicant should fully describe the variables that are controlled or monitored in the physical environment and should describe expressly prohibited functions. Timing information is particularly important in specifying software requirements for safety system software. The licensee or applicant should identify the functions with timing constraints and provide criteria for each mode of operation. Timing requirements should be deterministic and specified for both normal and anticipated failure conditions. DG-1209, Page 7 c. Consistency. Subclause 4.3.4 of IEEE Std. 830-1998 restricts the term “consistency” to mean internal consistency, noting that an external inconsistency is actually an incorrect specification of a requirement. The NRC uses the term in this regulatory guide to mean both internal and external consistency. External consistency implies that the SRS is consistent with associated