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:
onfiguration management and endorses IEEE Std. 828-2005, “IEEE Standard for Software Configuration Management Plans,” issued 2005 (Ref. 20). 4. Incomplete Software Requirement Specifications Entry Any entry in an SRS that is incomplete (i.e., uses “to be determined” or “TBD”), as described in Subclause 4.3.3.1 of IEEE Std. 830-1998, must describe the applicable design bases and commitments to standards or regulations that govern the final determination of the requirement entry. 5. Design-Specific Issues Subclause 4.7 of IEEE Std. 830-1998 recommends that design-specific issues, such as module partitioning, function allocation, and information flow, be omitted from SRSs. Subclause 4.7.1 of IEEE Std. 830-1998 states some exceptions to this policy, including reasons of security or safety. When specific design techniques or features, such as independence, separation, diversity, and defense in depth, are required by the safety system design bases or by regulation, they are an appropriate part of an SRS and should be described therein. 6. Software Attributes Subclause 5.3.6 of IEEE Std. 830-1998 lists software attributes that can serve as requirements. The following attributes are particularly of interest for safety system software: a. Safety. Software requirements important to safety are derived from system requirements and safety analyses and should be identified as such in the SRS. These requirements should include considerations based on the safety analysis report and on abnormal conditions and events as described in IEEE Std. 7-4.3.2-2003, which Regulatory Guide 1.152 endorses. b. Secure Analysis. IEEE Std. 830-1998, Subclause 5.3.6.3 “Security” is not endorsed as having sufficient detail to define specific factors for security attributes along with requirements that are applicable to the SRS. The requirements approach to include a security attribute is useful for the licensee or applicant, however an analysis of specific factors for the SRS can be