Page History

{alias:SWE-113}
{tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned}

{div3:id=tabs-1}

h1. 1. Requirements

5.2.5.1 The Software Change Request/Problem Report shall contain: \[SWE-113\]

a.    Identification of the software item.
b.    Description of the problem or change to enable problem resolution or justification for and the nature of the change, including: assumptions/ constraints and change to correct software error.
c.    Originator of Software Change Request/Problem Report and originator's assessment of priority/severity.
d.    Description of the corrective action taken to resolve the reported problem or analysis and evaluation of the change or problem, changed software configuration item, schedules, cost, products, or test.
e.    Life-cycle phase in which problem was discovered or in which change was requested.
f.     Approval or disapproval of Software Change Request/Problem Report.
g.    Verification of the implementation and release of modified system.
h.    Date problem discovered.
i.      Status of problem.
j.      Identify any safety-related aspects/considerations/ impacts associated with the proposed change and/or identified problem.
k.    Configuration of system and software when problem is identified (e.g., system/software configuration identifier or list of components and their versions).
l.      Any workaround to the problem that can be used while a change is being developed or tested.

h2. {color:#003366}{*}1.1 Notes{*}{color}

Note: The Software Change Request/Problem Report provides a means for identifying and recording the resolution to software anomalous behavior, process non-compliance with plans and standards, and deficiencies in life-cycle data or for identifying and recording the implementation of a change or modification in a software item.

h2. 1.2 Applicability Across Classes

Classes C through E and Safety Critical are labeled, "P(Center) + SO".  This means that this requirement applies to the safety-critical aspects of the software and that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement

Class F and Class G are labeled "X (not OTS)".  This means that this requirement does not apply to off-the-shelf software for these classes.

{applicable:asc=1\|ansc=1\|bsc=1\|bnsc=1\|csc=p\|cnsc=p\|dsc=p\|dnsc=0\|esc=p\|ensc=0\|f=1\|g=1|h=0|}
{div3}
{div3:id=tabs-2}

h1. 2. Rationale

Using standard formats for capturing requests for changes and problems found with software allows review boards (e.g., CCBs) to have a standard format for reviewing and dispositioning the requests/reports.  Including required content in these standard formats also helps capture the important information needed to review and resolve the documented change or problem.  Capturing descriptions, dates, and corrective actions provides for a complete picture of the request, its resolution, and its progress (for tracking purposes).  This information can be critical to project management. Some captured information may also allow for trending (life-cycle phase), estimation of future efforts (date found, date resolved) for similar issues, and lessons learned.
{div3}
{div3:id=tabs-3}

h1. 3. Guidance

_{floatbox:width=full}Per the\_ [NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126]\_, problem reports describe "unexpected behavior of the software or system, the analysis performed to determine the cause, and what was done to correct the problem. Projects usually have a formal system for problem reports after the software has reached a level of maturity. However, defects or problems that occur before this time are also important. Tracking these problems, or at least reviewing them to make sure no major defect slips through, is recommended in safety-critical systems."  {floatbox}_

Per the [NASA Software Safety Standard|https://standards.nasa.gov/documents/detail/3314914], "Discrepancy reports contain a description of each problem encountered, recommended solutions, and the final disposition of the problem."  This is typically minimal content for a change request or problem report.  NPR 7150.2A requirement SWE-113 (shown above) provides a longer list of required content for change requests and problem reports.  This required content is intended to capture:
* Information that describes what needs changed and why
* Information necessary to process the request (e.g., by a CCB)
* Information needed to authorize the change
* Information needed to determine the impact and necessity of the change

{panel}Typically, change requests are initiated by the person finding the problem such as the customer, developer, or tester.  These reports are reviewed for safety implications; therefore, the content should be as clear and as complete as possible. {panel}

For contracted software development, required problem report/change request content should be included in any contract or MOA/MOU so that contractors (providers) capture the required information in their reporting systems.

Projects may choose to use change tracking, change management, problem reporting, or other tools to capture and manage change requests and problem reports to closure.  These tools may also facilitate metrics capture and trending.  Most tools allow some type of customization such that the project's required information can be captured and managed within the tool.  When choosing a change request or problem report tool, consider the information that must be captured and the ability of the tool to collect or be configured to collect that information. 

Guidance for individual elements of the required change request/problem report content is included below:

*Identification of the software item* -- name and version of configuration item (code module, document, test, or other item).

*Description of the problem or change to enable problem resolution or justification for and the nature of the change, including: assumptions/ constraints and change to correct software error* -- description of the problem, including steps to reproduce the issue, data entered, expected results, actual results, what the user sees or experiences; need for the requested change including relevant details to explain the reason for the change.

*Originator of Software Change Request/Problem Report* -- originator's name, organization, and contact information.

*Originator's assessment of priority/severity* -- originator's opinion regarding urgency of the problem or requested change; may not be the same as the development organization's assessment since originator and developer have different perspectives; may be one of high, major, low or any other defined criteria that can be used to classify the request/report.

*Description of the corrective action taken to resolve the reported problem or analysis and evaluation of the change or problem, changed software configuration item, schedules, cost, products, or test* -- description of the changes made to address the change request or problem report; description of any associated problem analysis, such as an impact analysis; list of changed configuration items, including code modules, test documentation, requirements, design, and other project documents.

*Life-cycle phase in which problem was discovered or in which change was requested* -- For example, Phase B (Preliminary Design), Phase E (Operations & Sustainment); or requirements, design, development/implementation, integration test, etc.

*Approval or disapproval of Software Change Request/Problem Report* -- disposition of the request/report, typically from a configuration control board (CCB); additional details such as urgency category, disposition date, priority (high, medium, low), severity (inconvenience, halts operation, safety issue, security issue), comments.

*Verification of the implementation and release of modified system* -- unit, integration, system tests run to verify the change and their respective results; test witnesses, if appropriate; name of verifier; date of verification; released software version that contains the change; release date.

*Date problem discovered* -- date of request or date when problem first surfaced.

*Status of problem* -- current status of the change request/problem report using predefined status values such as new, analysis, assigned, implemented, tested, closed; will change as the request is processed and the problem or change is addressed and moved to resolution; could include status change date for tracking purposes.

*Identify any safety-related aspects/considerations/ impacts associated with the proposed change and/or identified problem* -- description of features, effects, impacts, behavior, or other factors related to or which affect or could affect the safety of the software or system.

*Configuration of system and software when problem is identified (e.g., system/software configuration identifier or list of components and their versions)* -- software version, system configuration/setup, installed options/components.

*Any workaround to the problem that can be used while a change is being developed or tested* -- steps to keep system functioning without triggering the problem while the problem is addressed and corrected.

* *

Additional information may be captured based on project needs, tracking requirements, data for metrics, or other reasons.  Sample information includes:
* Change request/problem report number/identifier; unique identifier
* Brief title or description for the request/report
* Date entered  - date report submitted; may not be same as date problem discovered
* Project name or identifier - if change request/problem reports for multiple projects are captured in a single tool
* Requirements statement, if request is for enhancement
* Attempts to repeat the problem (not typical for customer-entered reports, but expected for testers)
* Witnesses, observers (may be able to provide analysis data from their perspective)
* Attachments -- additional explanatory data such as test data or results
* Additional comments
* Detailed analysis data: e.g., analysis effort, recommendation, analyst name, completion date, analysis text, root cause (problem reports only)
* Assigned developer
* Effort spent designing, implementing, testing the change or correction
* Type of change: logic, interface, data, computation, or other defined change category
* Lines of code (LOC) affected by the change
* Affected baseline: functional, allocated, product
* Date completed

{panel}Consult center Process Asset Libraries (PALs) for center-specific guidance and resources related to the content of change requests/problem reports.
{panel}

Additional guidance related to the content of change requests/problem reports may be found in the following related requirement in this handbook:
| [SWE-080|https://nasa7150.onconfluence.com/display/7150/SWE-080] | Track & Evaluate Changes |
{div3}
{div3:id=tabs-4}

h1. 4. Small Projects

Projects with limited budgets may consider using simple tools such as document templates (MS Word) to capture change requests/problem reports and spreadsheets or simple databases for tracking and metrics generation.  Another option is to determine if any tools are available at the Center level or from previous projects which can be used a no or low cost to the current project.
{div3}
{div3:id=tabs-5}

h1. 5. Resources

# NASA Technical Standard, [NASA Software Safety Standard|https://standards.nasa.gov/documents/detail/3314914], NASA-STD-8719.13B, 2004.
# NASA Technical Standard, [NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126], NASA-GB-8719.13, 2004.
# IEEE Computer Society, [IEEE Standard for Software Configuration Management Plans|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1502775&tag=1], IEEE STD 828-2005, 2005 (need user account to access IEEE standards via this [NASA Technical Standards System|http://standards.nasa.gov/] link).
# IEEE Computer Society, [IEEE Guide to Software Configuration Management|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=89631&tag=1], IEEE STD 1042-1987, 1987 (need user account to access IEEE standards via this [NASA Technical Standards System|http://standards.nasa.gov/] link).
# Software Engineering Laboratory Series, Software Measurement Guidebook, Revision 1, SEL-94-102, 1995.
# STEP Level 2 Software Configuration Management and Data Management course, SMA-SA-WBT-204, 2010 (need user account to access course in [SATERN|https://saterninfo.nasa.gov/]). Users will need to log in to their SATERN account to access this resource.
# NASA Technical Standard, [NASA Configuration Management (CM) Standard|https://standards.nasa.gov/documents/detail/3315133], NASA-STD-0005, 2008.
# [Requirements for Minimum Contents of Software Documents|http://software.gsfc.nasa.gov/AssetsApproved/PA1.0.0.2.doc], 580-STD-077-01, GSFC, 2010.
# [Change Request Form|http://software.gsfc.nasa.gov/AssetsApproved/PA2.2.2.3.dot], Version 0.4, GSFC.
# [Software Change Request (SCR)|http://software.grc.nasa.gov/pilot/Templates%20&%20Forms/SOFTWARE%20CHANGE%20REQUEST%20FORM.doc], GRC.
# Boeing, [Software Change Control|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499394%2FBoeing_317.doc], HOU-EGP-317, 2002.
# Boeing, [Software Configuration Management|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499397%2FBoeing_322.doc], HOU-EGP-322, 2002.
# [Software Change Request Form|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499238%2FSOFTWARE%2BCHANGE%2BREQUEST%2BFORM.doc.doc] (high, medium, low control).



h2. 5.1 Tools

{panel}Tools relative to this SWE may be found in the table above. If no tools are listed, none have been currently identified for this SWE. You may wish to reference table XYZ i in this handbook for an evolving  list of these and other tools in use at NASA.  Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool.  *Check with your Center to see what tools are available to facilitate compliance with this requirement.* {panel}
{div3}
{div3:id=tabs-6}

h2. 6. Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to change requests and problem reports:
* *Problem Reporting and Corrective Action System*: "Hardware/software problems that require further investigation may not be identified and tracked. Development of corrective action and need for improvement will not be highlighted to engineering. Opportunities for early elimination of the causes of failures and valuable trending data can be overlooked..."       A closed-loop Problem (or Failure) Reporting and Corrective Action System (PRACAS or FRACAS) is implemented to obtain feedback about the operation of ground support equipment used for the manned spaceflight program." ([http://www.nasa.gov/offices/oce/llis/0738.html|http://www.nasa.gov/offices/oce/llis/0738.html])



* *Pre-Flight Problem/Failure Reporting Procedures*: "Without ... formal reporting procedures, problems/failures, particularly minor glitches, may be overlooked or not considered serious enough to investigate or report to Project Management. This could result in recurrence of the problem/failure during the mission and result in significant degradation in performance." ([http://www.nasa.gov/offices/oce/llis/0733.html|http://www.nasa.gov/offices/oce/llis/0733.html])
{div3}
{tabclose}