Problem Report Template#

This template defines the content to be implemented in the selected Issue Tracking System of the project.

Problem status#

[“open”, “in review”, “in implementation”, “closed”, “rejected”]

(to be filled out during Create Problem Report)
(to be updated during Analyze Problem Report)
(to be updated during Initiate and Monitor Proble...)
(to be updated during Close Problem Resolution)

Problem submitter#

[Who is the reporter of the problem?]

(to be filled out during Create Problem Report)

Problem description#

[What is the problem?]

Describe the observed deviation and its known or potential impact.
Document the cause, if known; otherwise record that it is under investigation.
(to be filled out during Create Problem Report)
(to be updated during Analyze Problem Report)

Problem notifications#

[Is notification needed, and who was notified?]

Record whether notification is needed and why. If needed, record who was notified, when and how, for example a link to an issue comment with an explicit mention or an email reference. Listing a recipient alone does not record a performed notification. See Notification of Affected Parties.

(to be filled out during Create Problem Report, as far as known)
(to be updated during Analyze Problem Report)

Problem supporting information#

[How to reproduce the problem?]

Add additional information, e.g.
add which operational state the problem occurred?
observations, screenshots, debug traces, etc.

[Error occurrence rate?]

Select one [None | Single Event | Sporadic | Highly Intermittent | Reproducible]
(to be filled out during Create Problem Report)
(to be updated during Analyze Problem Report)

Problem category#

[Safety affected, Security affected]

Safety, Security: Additional qualifiers to highlight, if safety or security is affected

Record whether safety or security is affected. If uncertain, state this for analysis. If neither is affected, the problem is quality relevant.

In addition to the category Safety affected, the ASIL classification may be added in the documentation, if applicable.

(to be filled out during Create Problem Report)
(to be updated during Analyze Problem Report)

Problem classification#

[minor, major, critical, blocker]

Classify the problem severity

Use minor, if the impact is not significant of the project

  • The problem does not restrict usage of features in a significant manner

Resolution may be scheduled to any planned future SW release
Use major, if the impact does effect the quality of the project

  • The problem can be solved with workarounds for affected features

Resolution shall be scheduled to next planned future SW release
Use critical, if the impact does not prohibit to use the project, but quality cannot be guaranteed

  • The problem affects a complete feature, that they are partly or complete not behave as expected

Resolution shall be scheduled to next planned future SW release or to a new planned intermediate release, if urgent resolution is required
Use blocker, if the impact prohibits using the project

  • The problem affects more than one feature, that they are partly or complete not behave as expected OR

  • Safety or Security risks identified

Resolution shall be provided upon availability

Note

In case of doubt, a safety or security relevant problem shall always classified as blocker.

Determine if Urgent resolution is required? (yes, no, only valid for critical, blocker)

(to be filled out during Create Problem Report)
(to be updated during Analyze Problem Report)

Problem affected versions#

[Where was the problem detected, and which versions are affected?]

Document the detection version and the first and last affected versions, including versions derived from the faulty version. Add affected branches or dependent integrations where applicable. Record unknowns as “under investigation” and update them during analysis.

(to be filled out during Create Problem Report, as far as known)
(to be updated during Analyze Problem Report)

Problem analysis results#

[What is the problem analysis result? Accepted or Rejected?]

Record the analysis result and the reason for rejection, if applicable.

The responsible Safety Manager confirms or disconfirms safety relevance where safety may be affected; the responsible Security Manager does so where security may be affected. Record the reason, especially when disconfirming relevance.

(to be filled out during Analyze Problem Report)

Problem stakeholder#

[What are the potential stakeholder to resolve the problem?]

Add affected features, if applicable

(to be filled out during Analyze Problem Report)

Problem expected closure version#

[Version when the problem should be resolved]

Document the version of the release where the problem should be resolved.

Optionally add a concrete Milestone, if applicable.

(to be filled out during Analyze Problem Report)

Problem solutions#

[What are measures to solve the problem?]

Specify the measures to resolve the problem, based on a rationale

Verify the effectiveness of the implemented measure

Report the results of the verification, if applicable

Are all arguments convincing

(to be filled out during Initiate and Monitor Proble...)
(to be updated during Close Problem Resolution)

Problem closure where safety is affected#

[Which safety-specific closure condition is met, and what supports it?]

Select and justify one condition according to Closure of Problems Where Safety Is Affected:

  • An adequate safety measure is implemented and its effectiveness is verified.

  • A risk evaluation concludes that the problem does not constitute an unreasonable risk.

Document the rationale, supporting verification results or risk evaluation, and the rationale review result.

(to be filled out during Close Problem Resolution)

Problem escalations#

[Document escalation activities, if applicable]

(to be filled out during Initiate and Monitor Proble...)
(to be updated during Close Problem Resolution)