Software Quality Assurance Criteria Review and Approach Documents

Safety Software Quality Assurance

Draft 3/31/2006

Note to assessors: The suggested lines of inquiry and review approach found within this document represent the collective insights and knowledge of DOE assessors who have conducted assessments in this area.  If you have specific lines of inquiry that have proven useful in deterring the effectiveness of program elements,  please forward them to us at loi@www.2004-1.org so other DOE assessors can benefit from your knowledge and experience.

Performance Objective 1: Contractor Program Documentation:

While this performance objective is focused on the Contractor, there are instances where DOE may be the performer of the work. Where DOE is the performer the contractor requirements as stated herein apply to the DOE organization doing the work.

1.1 Safety Software Inventory:  An inventory of safety software is identified, documented, and maintained.

Approach:

• Determine the existence of a safety software inventory list. This maybe evidence by an electronic or hardcopy data set. The inventory list may be a subset of a larger software inventory list.
• Ensure that the safety software can uniquely be defined.
• Use sampling methods to determine the accuracy and thus maintenance of the inventory list.

Lines of Inquiry:

• Does a list of safety software, as defined by DOE O 414.1C, documented?
• Is each item on the safety software uniquely identifiable?
• Is the inventory list current and accurate?

1.2 Safety Software Graded Approach: Establish grading levels for safety software. Document those grading levels in the QAP. [Suggested rewrite] Grading levels for safety software are established and documented in the QAP.

Approach:

• Determine the existence of grading levels for safety software.
• Review the grading levels for consistency and completeness with the graded approach as defined in 10 CFR 830 and DOE O 414.1C.
• Determine if the document(s) containing the safety software grading levels is approved by DOE.

Lines of Inquiry:

• Are the grading levels for safety software documented?
• Are these grading levels consistent and complete as defined by the graded approach in 10 CFR 830 and DOE O 414.1C?
• Has the document containing the grading levels for safety software been approved by DOE?

1.3 Safety Software Quality Assurance Consensus Standard: ASME NQA 1-2000, Quality Assurance Requirements for Nuclear Facility Applications, or other national or international consensus standards that provide an equivalent level of quality assurance requirements as ASME NQA 1 2000, are specified by the user and approved by DOE.

Approach:

• Determine the consensus standard(s) specified for safety software quality assurance use. If the standard(s) specified is not ASME NQA-1-2000, review the documentation to establish equivalence of the specified standard(s) to ASME NQA-1-2000.
• Determine if the specified standard(s) for safety software quality assurance is approved by DOE.

Lines of Inquiry:

• Has a consensus standard been specified for safety software quality assurance use?
• Has the specified consensus standard(s) been approved by DOE for safety software quality assurance?
• Is this safety software quality assurance standard, ASME NQA-1-2000?
• If the specified standard(s) is not ASME NQA-1-2000, has an equivalency document been developed?
• If an equivalency document has been developed, does it prove the specified standard(s) provides an equivalent level of software quality assurance as ASME NQA-1-2000 in the following work activities?
  • Software project management and quality planning.
  • Software risk management.
  • Software configuration management.
  • Procurement and supplier management.
  • Software requirements identification and management.
  • Software design and implementation.
  • Software safety.
  • Verification and validation.
  • Problem reporting and corrective action.
  • Training of personnel in the design, development, use, and evaluation of safety software

Performance Objective 2: Contractor Program Implementation:

Work processes involving safety software must be developed and implemented using the DOE approved national or international consensus standards (as per the criteria in Section 1.3 above) and must include the following elements.

2.1 Facility Design Authority Involvement: Facility design authority is involved in the identification of software requirements specification, acquisition, design, development, verification and validation (including inspection and testing), configuration management, maintenance, and retirement.

Approach:

• Review safety software development and acquisition documents such as safety software requirements, procurement or acquisition contracts and other documents, software development plans and documents, verification and validation documents, software configuration management documents, software maintenance documents, and software retirement plans for facility deign authority involvement in the document reviews and approvals.
• Interview facility design authority personnel and safety software development and quality assurance staff for the level of involvement of the facility design authority staff.

Lines of Inquiry:

• Is the facility design authority on the list of reviewers and/or approvers of the safety software development documents or their equivalent that are listed below:
  • safety software requirements?
  • safety software development plans?
  • safety software verification and validation plans?
  • safety software configuration management plans?
  • safety software test plans?
• Is the facility design authority on the list of reviewers and/or approvers of the safety software procurement or acquisition contracts?
• Does the facility design authority have a direct communication line with the safety software development?

2.2  Select and Implement Work Activities:  Using DOE approved grading levels (as per the criteria in Section 1.2 above) and ASME NQA-1-2000, Quality Assurance Requirements for Nuclear Facility Applications, or other DOE approved national or international consensus standards that provide an equivalent level of quality assurance requirements as ASME NQA 1 2000, applicable SQA work activities are selected and implemented from the following list to ensure that safety software performs its intended functions.

Approach:

• Review software or quality assurance plans and documents, to determine if the 10 work activities have been evaluated to determine their applicability and requirement for full or graded implementation. The applicability of a work activity may be determined by the software type such as custom or acquired. A matrix using the approved grading levels, the software type and the 10 work activities may provide evidence that the work activities have been evaluated.
• Use sampling methods to determine if the work activities identified through the work activity evaluation process have been implemented. This determination is associated with the assessment of the 10 work activities that are sub-elements to this Performance Objective.

Lines of Inquiry:

• Has a classification/category such as software type to determine appropriateness for applying the 10 work activities been defined?
• Has each of the 10 work activities been evaluated to determine their applicability under the above mentioned classification/category?
• Does the applicability (i.e., selection) address the approved graded approach?
• For each of the 10 work activities, has the selected work activities been implemented?

2.3 Software Project Management and Quality Planning: Software project management and quality planning depicts the organizational structure that supports the software life-cycle stages and deliverables, and influences and controls the quality of the software.

Approach:

• Confirm the existence of project management and QA planning work activity. This may be present in software project management and/or SQA plans that exist either as a stand alone document or embedded in other documents and related procedures. The software project management and software quality planning should identify and/or define the following:
  • software project schedule;
  • software project scope;
  • software engineering activities, including software requirements and design;
  • software V&V activities, including reviews and test;
  • SCM activities;
  • software risk management approach;
  • software safety analysis and planning;
  • supplier control;
  • user and software staff training,
  • standards, practices, conventions, and metrics;
  • records and document collection, maintenance, and retention; and
  • problem reporting and corrective action methods.
• Many of the items listed above may be detailed in other documents, for instance software V&V may be detailed in a software V&V plan or in software test plans. It should be noted that this work activity addresses the existence that these items are identified and described. Associated work activities, such as software V&V address the quality of the software V&V work activity being performed as it relates to the grading level.
• Determine whether the documents containing the software project management and quality plan are controlled under configuration change control and document control process, and are maintained until the software is retired. This may overlap with the SCM work activity.
• Verify that the software project management and quality plan is reviewed and updated, as necessary, for completeness and consistency. This may overlap with the software V&V work activity.

Lines of Inquiry:

• Are the software specific activities and tasks described, identified and documented?
• Are these activities and tasks sufficient to properly manage and control the software project and produce the required level of quality?
• Do these plans identify the organizational structure associated with the project management and quality planning?
• Are these plans initiated early and maintained throughout the software development life-cycle?
• Are these plans reviewed, approved and controlled?
• Do these activities and tasks include the following:
  • software project schedule?
  • software project scope?
  • software engineering activities, including software requirements and design?
  • software V&V activities, including reviews and test?
  • SCM activities?
  • software risk management approach?
  • software safety analysis and planning?
  • supplier control?
  • user and software staff training?
  • standards, practices, conventions, and metrics?
  • records and document collection, maintenance, and retention?
  • problem reporting and corrective action methods?

2.4 Software Risk Management: Software risk management utilizes a proactive and disciplined approach to assess and control software risks.

Approach:

• Determine the existence of software risk management planning. This may be evident in a standalone document or embedded in another document. As applicable, ensure that the risk management planning specifies the following:
  • scope of the risk management activities;
  • risk management policies and process (for both technical and managerial) under which risk management is to be performed are defined;
  • identification of the technical and managerial risks and likelihood and potential safety consequences;
  • establishment of risk thresholds for the safety software application;
  • risk avoidance, mitigation, or transfer options; and
  • management techniques to address risks throughout project life-cycle, including tracking, decision, and feedback points.

Lines of Inquiry:

• Have the risks associated with the successful completion of the software development or procurement been identified and documented?
• Do these risks include risks associated with costs, resource availability, schedule, and technical aspects?
• Have risk thresholds been identified and applied?
• Are the risks evaluated for impact and probability of occurrence initially and periodically through the software life-cycle?
• Are the risks prioritized and tracked through the software life-cycle?
• Are actions taken to mitigate the risks using avoidance, risk reduction, and/or transfer of risks approaches?

2.5 Software Configuration Management: Software configuration is defined, maintained, and controlled until the software is retired.

Approach:

• Review appropriate documents, such as applicable procedures related to safety software change control to determine if an SCM process exists and is effective. This determination is made based on the following actions.
• Verify the existence of documented processes to control, uniquely identify, describe, and document the configuration of each version or update of safety software and its related documentation. This documented evidence may be in either SCM plan or embedded in another software or system level document.
• Verify that a configuration baseline is defined and that it is being adequately controlled. This baseline should include operating system components, any associated runtime libraries, acquired software executables, custom-developed source code files, users' documentation, the appropriate documents containing software requirements, software design, software V&V procedures, test plans and procedures, and any software development and quality planning documents.
• Verify a baseline labeling system has been created that uniquely identifies each configuration item, identifies changes to configuration items by revision, and provides the ability to uniquely identify each configuration.
• Review procedures governing change management for installing new versions of the software components, including new releases of acquired software.
• Review software change packages and work packages to ensure that (1) possible impacts of software modifications are evaluated before changes are made, (2) various software system products are examined for consistency and revised as necessary after changes are made and updated, (3) software is tested according to established standards after changes have been made, (4) changes are evaluated and approved for release by the responsible organization, and (5) software validation is performed as necessary to ensure that the change does not adversely affect the performance of the software.
• Verify by sampling that documentation affected by software changes accurately reflects all safety-related changes that have been made to the software.
• Interview a sample of cognizant line, engineering, and QA managers, and other personnel to verify their understanding of the change control process and commitment to manage changes affecting design, safety basis, and software changes in a formal, disciplined, and auditable manner.
• For custom developed safety software, verify audits or reviews, such as functional configuration audit or physical configuration audit, have been performed.

Lines of Inquiry:

• Are the methods used to control, uniquely identify, describe, and document the configuration of each version or update of software and its related documentation documented?
• Is a configuration baseline defined and adequately controlled?
• Does this baseline include operating system components, any associated runtime libraries, acquired software executables, custom-developed source code files, users' documentation, the appropriate documents containing software requirements, software design, software V&V procedures, test plans and procedures, and all software development and quality planning documents?
• Has a baseline labeling system been implemented that addresses the following:
  • Unique identification of each configuration item?
  • Changes to configuration items by revision?
• Is the baseline labeling system used throughout the life of the software development and operation?
• Are proposed changes to the software documented, evaluated, and approved?
• Is software baselined prior to approval for use?
• Are only approved changes made to the baselined software?
• Are software verification activities performed for the change to baselined software?
• For custom developed safety software, have audits or reviews, such as functional configuration audit or physical configuration audit, been performed?

2.6 Procurement and Supplier Management: Acquired safety software, either commercial off-the-shelf (COTS) software or custom-developed for DOE, meets the appropriate level of QA based on risk, safety, facility life-cycle, complexity, and project quality requirements.

Approach:

• Suppliers of acquired software are evaluated to ensure that the safety software is developed under an appropriate QA program and satisfies the specific requirements. The assessment of software procurement process should include the following:
  • Determine the existence of safety software technical and QA requirements. These requirements may be embedded in the DOE contractors' or subcontractors' procurement document, software or system design description, or SQA plan. If not documented in the procurement contract, ensure that the supplier has received such technical and QA requirements. This verification may overlap with the Software Requirements Management work activity.
  • Verify that the suppliers' QA program has been reviewed and meets or exceeds the procurement specification requirements. The supplier may review the supplier's QA program through supplier assessment, supplier self declaration, third-party certification, or other similar methods.
  • Review evidence that the acquired software was evaluated for the appropriate level of quality. This evidence may be included in the test results, a test summary, supplier site visit reports or supplier QA program assessment reports. This review may overlap with the V&V work activity.
  • Review procurement or other documents between the supplier and purchaser for a documented process to report software defects from the supplier to the purchaser and the purchaser to the supplier. This review may overlap with the Problem Reporting and Corrective Action work activity.

Lines of Inquiry:

• Does the procurement and supplier documentation include both the technical and quality requirements including the following categories of software requirements:
  • Functionality?
  • Safety?
  • Security?
  • Performance?
  • Quality?
• Does the procurement and supplier documentation include all documents to be provided to the customer?
• Do the procurement and supplier documents include requirements for or the procedures for supplier notification of defects, new releases and other issues?
• Do the procurement and supplier documents include requirements for or the procedures for users to report defects and requests for assistance?
• Has the delivered product been assessed or otherwise validated to ensure requirements have been met? This evidence may be included in the test results, a test summary, supplier site visit reports or supplier QA program assessment reports.
• Has the suppliers' QA program been reviewed to ensure it meets or exceeds the procurement specification requirements? This may include review of the supplier's QA program through supplier assessment, supplier self declaration, third-party certification, or other similar methods.

2.7 Software Requirements Identification and Management: Safety software functions, requirements, and their bases are defined, documented and managed throughout the safety software life-cycle.

Approach:

• Review appropriate safety basis documents, such as DSAs, safety analysis reports, TSRs, procurement specifications and any system documentation to determine if the safety software requirements document is consistent with the safety system design and safety basis. The software requirements may exist either as a standalone document, such as a software requirements specification, or embedded in other system or software level documents.
• Determine whether the following types of requirements are addressed as appropriate:
  • Verify that the software requirements address functionality, performance, security, safety design inputs, design constraints, installation considerations, operating systems (if applicable), and external interfaces necessary to design the software exist and are documented.
  • If access to the system by only authorized users is a requirement, verify that use of software is controlled so that only personnel on authorized user lists apply or maintain safety software.
  • Verify that the software requirements are correct, unambiguous, complete, consistent, verifiable, modifiable and traceable as appropriate.
  • Verify that acceptance criteria are established in the software requirements for each of the identified requirements. Such criteria should be used for V&V planning and performance as defined in each related life-cycle phase.
  • Verify that the software requirement documents are controlled under the configuration change control and document control processes. This may overlap with the SCM activity.
  • Verify that software requirement documents are reviewed and updated as necessary. This may overlap with the software V&V work activity.

Lines of Inquiry:

• Are the software requirements defined and documented throughout the safety software life-cycle?
• Are the software requirements uniquely identified?
• Are the requirements controlled and maintained throughout the safety software life-cycle to minimize conflicting requirements and to maintain accuracy?
• Are the software requirements traceable throughout the software life-cycle?
• Are changes to the software requirements updated in any and all documents?
• Are the requirements consistent with the safety system basis?
• Do the software requirements address each type of the following categories:
  • Functional?
  • Performance/timing?
  • Security, including user access restrictions?
  • Interface?
  • Safety?
• Are the software requirements complete, correct, consistent, clear, testable and feasible?
• Can the software requirements be objectively verified and validated?

2.8 Software Design and Implementation: The safety software design depicting the logical structure, information flow, logical processing steps, data structures and interfaces are defined and documented. The design is properly implemented in the safety software.

Approach:

• Review the appropriate documents, including design documents, review records, and source code listings. The design may be documented in a standalone document or embedded in other documents.
• The software design description should contain the following information:
  • A description of the major safety components of the software design as they relate to the software requirements, and any interactions with non-safety components.
  • A technical description of the software with respect to control flow, control logic, mathematical model, data structure and integrity, and interface.
  • A description of inputs and outputs including allowable or prescribed ranges for inputs and outputs.
  • A description of error handling strategies and the use of interrupt protocols.
  • The design described in a manner suitable for translating into computer codes.
• Evidence of reviews of the design and code for the appropriate grading exists. This may overlap with the software V&V work activity.
• Evidence of developer testing including any independent testing for the appropriate grading exists.

Lines of Inquiry:

• Is the safety software design complete and sufficient to meet the safety software requirements?
• Does the safety software design fully describe the interfaces with external components or systems?
• Does the safety software design describe how the software functions internally?
• Does the safety software design describe the control flow, control logic, mathematical model?
• Does the safety software design describe the inputs and outputs including allowable or their prescribed ranges?
• Does the safety software design describe the data structures and provide layouts of those structures?
• Does the safety software describe error handling strategies and the use of interrupt protocols?
• Has a traceability between safety software requirements and the design been performed and is documented?
• Have static analysis such as code reviews been performed on safety software code modules?
• Is the static analysis performed adequate coverage of critical safety software components?
• Was developer unit testing completed prior to system level testing?
• Was developer testing, including unit, integration, and system level testing, planned and documented?
• Does the developer testing include tests to address functions, code structure and logic, stress and load testing, software performance, and human factors?
• Have the results of developer testing been analyzed and documented?
• Where appropriate, have reviews and testing been performed by persons independent of the activity or code module being reviewed or tested?

2.9 Software Safety: The design of the safety software components is developed to ensure the software modules perform their intended safety function in a manner consistent with the implementation of the safety system.

Approach:

• Review hazard analysis documents to ensure that software component and interface failures are included. This analysis may be part of a software or system level failure modes and effects analysis, fault-tree analysis, event-tree analysis or other similar analysis techniques.
• Review how the identified hazards are resolved. Various methods are used for hazards resolutions, such as eliminations, reduction of exposure, and controlling or minimizing the effects of a hazard.
• Review that the hazard analysis is periodically reassessed throughout the software life cycle and the changes incorporated as appropriate.
• For Level A safety software, and optionally for Level B safety software, sample safety software modules for proof of design complexity evaluation and isolation of safety functions from non-safety functions.
• For Level A safety software, and optionally for Level B where safety software modules defects could impact the safe operation of the system, evaluate the software design for the implementation of fault tolerant and/or self-diagnostics techniques.

Lines of Inquiry:

• Has a hazard analysis of the software at the component level been performed and documented?
• Did the hazard analysis identify the potential failures, the consequences of those failures, and the probably of occurrence associated with those failures?
• Have actions been taken to eliminate or mitigate the identified failures based upon the consequences of failure and probability of occurrence?
• Was the hazard analysis periodically reviewed and reassessed for possible changes in identified hazards or the addition of new hazards?
• Have the changes to the hazards analysis been incorporated into the design of the safety software?
• For Level A safety software, are the safety software components isolated from non-safety software components?
• For Level A safety software, was the complexity of the software components used in evaluating the software design?
• For Level A safety software, have fault tolerant techniques been considered in the design?
• For Level A safety software, have fault detection and/or self diagnostics been considered in the design?

2.10 Verification and Validation (V&V): The V&V process and related documentation for software are defined and maintained to ensure, (1), the software correctly performs all its intended functions; (2), the software does not perform any adverse unintended function; and (3), the operation of the software addresses the original purpose, intent, and plan.

Approach:

Review appropriate documents, such as SQA plans, review plans, walkthrough records, peer review records, desk check records, inspection reports, test plans, test cases, test reports, test results, traceability matrices, system qualification plans and reports, and supplier qualifications to determine whether-

• management process exists for performing V&V and management and independent technical reviews;
• reviews and inspections of the software requirement specifications, procurement documents, software design, code modules, test results, training materials, and user documentation have been performed by staff other than those who developed the item;
• software design was performed prior to the safety software being used in operations;
• for software design V&V-
  • results of the safety software V&V are documented and controlled;
  • V&V methods include any one or a combination of design reviews, alternate calculations, and tests performed during program development; and
  • the extent of V&V methods chosen are a function of (1) the complexity of the software; (2) the degree of standardization; (3) the similarity with previously proved software; and (4) the importance to safety; and
• for software test V&V-
  • documentation for development, factory or acceptance testing, installation, and operations testing exists and is adequate;
  • documentation includes test guidelines, test procedures, test cases including test data, and expected results;
  • results documentation demonstrates successful completion of all test cases or the resolution of unsuccessful test cases and proves direct traceability between the test results and specified software design;
  • test V&V activities and their relationship with the software life-cycle are defined;
  • software requirements and system requirements are satisfied by the execution of integration, system and acceptance testing;
  • acceptable methods for evaluating the software test case results include (1) analysis without computer assistance, (2) other validated computer programs, (3) experiments and test, (4) standard problems with known solutions, and (5) confirmed published data and correlations;
  • traceability exists from software requirements to design and testing, and if appropriate, to user documentation; and
  • hardware and software configurations pertaining to the test V&V are specified.
• Observe or perform configuration management query tasks to address the lines of inquiry.

Lines of Inquiry:

• Are verification and validation activities performed by competent staff that is independent of the item being verified or validated?
• Are the verification and validation activities integrated with the software lifecycle and performed to ensure software requirements are correctly specified and implemented in the design, test documentation and released software code?
• Do management processes exist for performing each of the following:
  • Verification and validation activities?
  • Management reviews?
  • Independent technical reviews?
• Do the verification and validation activities include reviews and/or inspections of the following applicable items? (Note: these items may be combined or included with other system and software documentation.)
  • Software requirements specification
  • Software procurement criteria and documents
  • Software design
  • Code modules
  • User/operator training materials
  • Software development processes
  • Test results
• Have the software testing activities been planned and documented?
• Have the software testing plans been placed under configuration management?
• Do the software test plans include testing for development, factory or acceptance testing, installation, and operations tests?
• Do the software development, factory or acceptance testing, installation, and operations test cases and procedures include expected results?
• Are the software development, factory or acceptance testing, installation, and operations test cases, procedures, and test results documented?

2.11 Problem Reporting and Corrective Action: Methods for documenting software problem reporting, and corrective action for safety software errors and failures are established, maintained, and controlled.

Approach:

Review documents and interview facility staff for the problem reporting and notification process to determine whether-

• methods for documenting software problem reporting and corrective action development that addresses software errors, failures, and resolutions;
• problems that impact the operation of the software are promptly reported to affected organizations;
• corrections and changes are evaluated for impact and approved prior to being implemented;
• corrections and changes are verified for correct operation and to ensure that no side effects were introduced;
• preventive measures and corrective actions are provided to affected organizations in a timely manner; and
• the organizations responsible for problem reporting and resolution are clearly defined.

Lines of Inquiry:

• Are the practices and procedures for each of the areas below defined and documented?
  • Reporting problems or issues
  • Tracking those problems or issues
  • Resolving those problems or issues
• Are the above practices and procedures implemented as defined above?
• Does a process exist for evaluating if the reported problem or issue is a software defect, error or other source?
• Are responsibilities for the following activities identified?
  • Reporting issues
  • Approving changes
  • Implementing corrective actions
• Are the corrective actions implemented effective to ensure correct operation and no side effects were introduced?
• Are the defects and errors associated with the safety software defects and errors correlated with software elements?
• Has the potential impact of those defect and errors been evaluated?
• Are the preventative measures and corrective actions commensurate with the impact of the original defect?
• Have all users of the safety software been notified in a timely manner of the potential impact of the defects and errors?
• For acquired safety software, do the procurement documents include requirements for the supplier to report problems to the user or purchaser?
• For acquired safety software, do the procurement documents include requirements and/or procedures for the purchaser or user to report problems to the supplier?
• Confirm and identify the applicable parts of NQA-1-2000, or an equivalent consensus standard for the SQA requirements, have been used for this requirement

2.12 Training of Personnel in the Design, Development, Use, and Evaluation of Safety Software: Personnel are trained/qualified and capable of performing assigned work. Continuing training to personnel to maintain job proficiency is provided.

Approach:

• Review training records or other documentation and conduct interviews to confirm a training or indoctrination program exists for each of the personnel assignments listed above.
• Verify the training program provides for continuing education.
• Verify the training program is adequate and appropriate for the scope, complexity, and importance of the task being performed.

Lines of Inquiry:

• Does a training or indoctrination program exist for each of the following personnel assignments?
  • safety software analysis
  • software development (concept to retirement)
  • operations and use
  • assessment or evaluation of safety software
• Does the training or indoctrination program provide for continuing education and training for each of the above personnel?
• Does the continuing education and training improve the performance and proficiency for each of the above personnel?
• Is the training or indoctrination program designed according to the scope, complexity, and importance of the tasks, education and proficiency of the personnel?
• Confirm and identify the applicable parts of NQA-1-2000, or an equivalent consensus standard for the SQA requirements, have been used for this requirement.
• For Level A safety software, are metrics and measured used to determine the impact of the training or indoctrination program on personnel performance?
• For Level A safety software, are metrics and measured used to determine the impact of the training or indoctrination program on personnel proficiency?

Performance Objective 3: DOE Line Management Oversight Documentation:

Federal personnel have the technical competency to perform SQA responsibilities: Federal personnel with SQA responsibilities have technical competency to carry out their duties. Technical qualification requirements are specified in technical qualification standards. The process has been coordinated with the Federal Technical Capability Panel (FTCP) in accordance with the requirements of DOE M 426.1-1A, Federal Technical Capability Manual, dated May 18, 2004, and DOE STD-1172-2003, Safety Software Quality Assurance Functional Area Qualification Standard, dated December 2003.

Approach:

• Review the technical qualification records to determine the individual responsible for having the technical competency for safety software quality assurance.
• Review the qualification process of the individual to ensure it meets DOE M 426.1-1A.

Lines of Inquiry:

• Has DOE/NNSA identified an individual or individuals responsible for performing SQA responsibilities?
• Are each of these individuals qualified as per DOE STD-1172-2003, Safety Software Quality Assurance Functional Area Qualification Standard, dated December 2003?
• Did this qualification meet the process in accordance with DOE M 426.1-1A, Federal Technical Capability Manual, dated May 18, 2004?
• Has a Technical Qualification Program (TQP) approved SQA Functional Area Qualification (FAQ) card been completed for each of the individuals responsible for performing SQA responsibilities?