1.0 general information
1.1 Software Name and Version
1.2 TA Number(s)	1.3 Facility Number(s)
1.4 Intended Use
1.5 Software Designation (from Form 2033)	1.6 Software Risk Level (SRL)
☐	Safety Software: SSS (Safety System SW)	☐	1	☐	2	☐	3
☐	Safety Software: SHADS (Safety Hazard Analysis SW and Design SW)	☐	1	☐	2	☐	3
☐	Safety Software: SMACS (Safety Mgmt and Administrative Controls SW)	☐	1	☐	2	☐	3
☐	Non-safety: Risk Significant Software	☐	1	☐	2	☐	3
☐	Non-safety: Commercially Controlled Software	N/A

2.0 RISK REGISTER
2.1 Risk Event No.	2.2 Risk Event Title	2.3 Risk Event Description	Initial (unmitigated)	2.6 Risk Ranking (R)	2.7 Handling Strategy	2.8 Handling Action	2.9 Residual Risk	2.10 Status	2.11 Handling Action Owner	2.12 Comments
2.4 Probability	2.5 Consequence

3.0 REVISION HISTORY
3.1 Revision	3.2 Date	3.3 SWRR Revision Description and Reason for Revision
0	Initial issue.

GENERAL

This template may be used to implement the risk management requirements of both P1040, Software Quality Management and STD-342-100, LANL Engineering Standards Manual, Chapter 21-Software. Use of this template is not mandatory; other templates or formats may be used.

Software (project) risk management is the process of identifying what can go wrong, determining what risks are significant, and establishing what actions are needed to mitigate those risks. For safety software and risk significant software, the SQMP must include an appropriate risk management plan.

Examples of potential risks for software projects include:

incomplete or constantly-changing software requirements

software design changes during coding

minimal experience with use of a programming language

improper selection or use of programming languages

undefined or inadequate test acceptance criteria

insufficient user acceptance testing

unproven testing tools and test methods

insufficient time for software development, coding, and/or testing

incomplete or undefined interfaces (both organizational and software)

using unproven computer (hardware) and/or software technologies

new versions of the operating system or other support software

quality concerns with subcontractors or suppliers

insufficient user training

Note: Other risk management requirements and/or forms may apply depending upon the organization and operational procedures under which the software is being used.

For additional information on software (project) risk management requirements, see P1040, R11, Section 3.4.2, or contact an SQA representative at p1040@lanl.gov.

A fictitious example of this form is included following the form instructions.

HEADER

Enter the Document ID (e.g., number or letter) and Revision Number for the SWRR, per the governing document control process.

1.0 GENERAL INFORMATION

Field	Entry Information
1.1	Enter the name and version number of the software.
1.2	Enter the Technical Area number(s) where the software is approved for use.
1.3	Enter the facility number(s) where the software is approved for use.
1.4	Describe the intended use of the software (what the software does/how it is used).
1.5	Select the software determination from Form 2033. Check only one box.
1.6	Select the Software Risk Level (SRL). Check only one box.

2.0 RISK REGISTER

Field	Entry Information
2.1	Enter a sequential risk event number (No.). The leading digits should correspond to the work breakdown structure (WBS) of the risk event. An example of a high-level WBS is provided below. This WBS may be used if there is no existing WBS associated with the work. WBS 01 Plan The work associated with planning and managing software, including software quality management (SQM), through software approval for use. WBS 02 Design The work associated with the software design. WBS 03 Acquisition The work associated with software and hardware acquisition. Includes computer servers, computer workstations, etc. WBS 04 Install, V&V, and Approve for Use The work associated with software installation, Verification and Validation (V&V), and approval for use. WBS 05 Operate and Maintain The work associated with operating and maintaining the software and associated hardware. Includes SQM (e.g., problem reporting, corrective action, configuration management etc.) from approval for use through retirement.
2.2	Enter a short, descriptive title for the risk event.
2.3	Describe the risk event. The 3-sentence format below is recommended although other formats may be used. Describe the events as they relate to successfully completing the applicable steps in the software lifecycle. This includes software determinations, planning, acquisition, design, verification/validation, approval for use, inventorying, operating and maintaining the software. Sentence 1 - Normal Condition (the normal condition (situation) associated with the risk). Example: Personnel trained and knowledgeable with accident analysis software and its limitations, know how to properly operate it, and consistently produce acceptable results for facility safety basis documents. Sentence 2 - Event (an event that could happen that is different from the normal condition). Example: Personnel without adequate software training and knowledge incorrectly operate the software. Sentence 3 - Impact (what impact the event could have on the normal condition with respect to the software performance objectives, cost, and/or schedule impacts). Example: Personnel produce unacceptable accident analyses that require the analyses to be performed again at additional cost and time; result in customer loss of confidence in management; could result in inadequate facility administrative and/or engineered safety controls.
2.4	Enter the qualitative probability (likelihood) of the event occurring. Enter improbable, remote, occasional, probable, or frequent using the following table to guide the estimate. Improbable So unlikely that probability is close to zero (Frequency <0.001/year) Remote Unlikely though conceivable (Frequency >0.001 and <0.1/year) Occasional Could occur sometime (Frequency >0.1 and <1/year) Probable Occurs repeatedly/to be expected (Frequency >1/year and <2/year) Frequent Not surprised, will occur several times. (Frequency > 2/year)
2.5	Enter the relative consequence of the event (i.e., how bad the situation would be if the risk event occurred). Enter negligible, minor, serious, critical, catastrophic using the following table to guide the estimate. Negligible Negligible impact on performance objectives, cost and/or schedule Minor Minor impact on performance objectives and/or <5% cost overrun; <5% schedule slip Serious Moderate impact on performance objectives and/or; >5 to <10% cost overrun; >5 to <10% schedule slip Critical Major impact on performance objectives and/or; >10 to <15% cost overrun; >10 to <15% schedule slip Catastrophic Catastrophic impact on performance objectives and/or; >15% cost overrun; >15% schedule slip
2.6	Enter the qualitative risk ranking (Tolerable, Low, Medium, High, or Intolerable). Use the probability and consequence from steps 2.4 and 2.5 and the table below to determine the risk ranking. (Risk (R) = Probability (P) x Consequence (C)). Consequence Probability Negligible Minor Serious Critical Catastrophic Improbable Remote Occasional Probable Frequent Risk Legend Tolerable Low Medium High Intolerable
2.7	Enter the handling strategy (i.e., a one-word description of what will be done to address the risk). Enter Prevent, Mitigate, Transfer, or Accept based on the following: Prevent Avoid or eliminate the risk Mitigate Lower the consequence Transfer Transfer risk to another activity or entity Accept Accept the risk; take no action
2.8	Describe the actions that will be taken to handle (address) the risk and when they will be performed. If no action is taken (i.e., the risk is accepted), enter N/A.
2.9	Enter the residual qualitative risk ranking (e.g., Tolerable, Low, Medium, etc.). The residual risk ranking is the risk that remains after implementation of the handling strategy/actions. Use the table in step 2.6 to determine the residual risk.
2.10	Enter the status of the handling action. (e.g., 0 – 100% complete, ongoing, complete, etc.).
2.11	Enter the name and if applicable, Z number of the person responsible for implementing the handling action. The responsible person must have the authority and resources to complete the action.
2.12	Enter comments. If no comments, leave blank or enter none.

3.0 REVISION HISTORY

Field	Entry Information
3.1	As required, revise the SWRR per the governing document control procedure. Enter the SWRR revision number (or letter). Retain prior revision numbers (or letters).
3.2	Enter the date the revision took effect (effective date).
3.3	Enter a summary description of the SWRR revision and the reason(s) for the revision.

1.0 software INFORMATION
1.1 Software Name and Version	ACCS2, Version 2.1	1.2 TA	SWID-63-011-134

2.0 RISK REGISTER
2.1 Risk Event No.	2.2 Risk Event Title	2.3 Risk Event Description	Initial (unmitigated)	2.6 Risk Ranking (R)	2.7 Handling Strategy	2.8 Handling Action	2.9 Residual Risk	2.10 Status	2.11 Handling Action Owner	2.12 Comments
2.4 Probability	2.5 Consequence
04-01	Incorrect software operation by untrained personnel	Normal. Personnel trained and knowledgeable with the software properly use it and consistently produce acceptable results for facility safety basis documents. Event. Personnel without adequate software training and knowledge incorrectly operate the software. Impact. Personnel produce unacceptable analyses that (a) require the analyses to be performed again at additional cost and time; (b) result in customer loss of confidence in management; (c) could result in inadequate facility administrative and/or engineered safety controls.	Remote	Critical	Medium	Mitigate	Annually review and take appropriate staffing actions to ensure a minimum number of trained qualified personnel are on staff. Maintain subcontracts with qualified subcontractors to be able to access trained qualified personnel in ACCS2.	Low	Ongoing	Joe Jackson, 123456	None

2.1 Risk Event No.	2.2 Risk Event Title	2.3 Risk Event Description	Initial (unmitigated)	2.6 Risk Ranking (R)	2.7 Handling Strategy	2.8 Handling Action	2.9 Residual Risk	2.10 Status	2.11 Handling Action Owner	2.12 Comments
2.4 Probability	2.5 Consequence
04-02	Changes to Operating System (OS)	1. Normal. LANL mandated upgrades to a new Operating System (OS). 2. Event. LANL mandated upgrades to a new OS results in an OS system that is not compatible with ACCS2. 3. Impact. ACCS2 will not run properly on the new OS and will produce erroneous results that (a) require the analyses to be performed again at additional cost and time; (b) result in customer loss of confidence in management; (c) could result in inadequate facility administrative and/or engineered safety controls.	Occasional	Critical	High	Mitigate	Monitor Registry and use newer approved versions of ACCS2, compatible with new OS, once the newer version is added to the Registry. Obtain LANL formal exception to use existing OS that works with existing ACCS2 version.	Low	In progress On hold pending future LANL OS mandates	Joe Jackson, 123456	DOE reported to begin new Registry version evaluation in 11/2016