Linked Knowledge Nuggets: arrow_forward "What is meant by the term “problem” in the context of SUP.9?"
personAuthor: Process Fellows
Bugs aren’t the only problems. Unclear responsibilities, miscommunications, tool breakdowns – they all count. ASPICE expects you to log, analyze, and follow up on all kind of issues systematically.
arrow_forward "When and how to use supporting processes?"
personAuthor: Process Fellows
Supporting processes like SUP.9 (Problem Resolution) or SUP.10 (Change Request Management) are often misunderstood as “back-office.” But they’re vital for delivering quality. Make sure your teams know when to invoke them — and how to record their outcomes. A 2-minute log of a problem review can save hours of debugging.
# PROCESS PURPOSE
The purpose is to ensure that problems are identified, recorded, analyzed, and their resolution is managed and controlled.
# PROCESS OUTCOMES
O1
The problems are uniquely identified, recorded and classified.
O2
The problems are analyzed and assessed to determine an appropriate solution.
O3
Problem resolution is initiated.
O4
The problems are tracked to closure.
O5
The status of the problems including the trends identified are reported to the stakeholders.
# BASE PRACTICES
BP1
Identify and record the problems. (
O1, O4 )
Each problem is uniquely identified, described and recorded. A status is assigned to each problem to facilitate tracking. Supporting information is provided to reproduce and diagnose the problems. Note 1: Problems may relate to, e.g., product, resources, or methods. Note 2: Example values for the problem status are “new”, “solved”, “closed”, etc. Note 3: Supporting information may include, e.g., the origins of the problems, such as failed verification, how they can be reproduced, environmental information, by whom they have been detected. Note 4: Unique identification supports traceability to changes made as needed by the change request management process (SUP.10).
BP2
Determine the causes and the impacts of the problems. (
O1, O2 )
Analyze the problems, determine their causes, including common causes if existing, and impacts. Involve the relevant parties. Categorize the problems. Note 5: Problem categorization (e.g., light, medium, severe) may be based on severity, criticality, urgency, etc.
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward "Root cause analysis in problem resolution"
personAuthor: Process Fellows
Don’t just patch bugs. You should understand why the problem occurred. You may use 5 Whys, Ishikawa, or similar methods - when this is beneficial. It is not neccessary to always employ these methods, but: Implement systematic root cause analysis. Identify systemic issues – not just symptoms.
arrow_forward "The role of traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP3
Authorize urgent resolution actions. (
O3 )
Obtain authorization for immediate action if a problem requires an urgent resolution according to the categorization.
Linked Knowledge Nuggets: arrow_forward "Example of an urgent resolution action process flow"
personAuthor: Process Fellows
In case of critical issues, an urgent resolution action may be required, such as the implementation of a workaround or hotfix. It must be ensured that the underlying problem is subsequently addressed in a systematic and sustainable manner.
Stakeholder Notification:
All relevant stakeholders are promptly informed about the issue and the proposed urgent action.
Decision and Authorization:
The urgent resolution action is evaluated, decided upon, and formally authorized.
The decision is documented in the designated problem management tool.
Initiation of Problem Resolution:
The process to resolve the root cause of the issue is initiated immediately.
Temporary vs. Permanent Solution:
If the urgent action only provides a temporary fix, a change request for a permanent solution must be created and tracked accordingly. The change request should include a trace link to the originating problem to ensure full traceability.
BP4
Raise alert notifications. (
O3 )
If, according to the categorization, problems have a high impact on other (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) or other affected parties, alert notifications need to be raised accordingly.
Linked Knowledge Nuggets: arrow_forward "When to raise an alert – practical examples"
personAuthor: Process Fellows
There could be many scenarios where a notification about a problem should be send to relevant stakeholders (typically outside of the project, where the problem was identified). Do not mix this up with the need for urgent resolution or escalation. First of all we are talking about a notification only. But of course, depending on the impact of the problem, the notified stakeholders could ask for an urgent action.
Example Scenario 1 – Cross-Project Component Dependency
Context:
Project A is reusing a component or platform that was originally delivered and is currently maintained by another project, Project B.
Situation:
Project A identifies a problem, and the root cause is traced back to the reused component from Project B. In this case, Project A must inform Project B about the issue.
Urgency and Impact:
Depending on the severity and impact of the problem, this may require an urgent resolution action from Project B.
In addition, project B must assess whether the affected component is also being used by other projects (e.g., project C).
If so, project B is responsible for informing all dependent projects to ensure coordinated communication and risk mitigation.
Example Scenario 2 - Cross-Generational Product Issue Escalation
Context:
Project B is developing a "next-generation" version of a product that was originally created by Project A as the "first-generation" version.
Situation:
During development, Project B identifies a problem. A root cause analysis reveals that the same issue also affects the first-generation product. Despite thorough qualification during its initial development, the problem was not detected earlier. The first-generation product is already in mass production and has been released to the market.
Urgency and Impact:
Depending on the severity of the issue, corrective actions may include a product recall. Additionally, customers who have purchased the first-generation product may need to be proactively informed and warned about potential risks associated with continued use.
BP5
Initiate problem resolution. (
O3 )
Initiate appropriate actions according to the categorization to resolve the problems long-term and prevent recurrence, including reviews of those actions, or initiate change requests. This includes synchronization and consistency with short-term urgent resolution actions, if applicable.
BP6
Track the problems to closure. (
O4, O5 )
Track the statuses of the problems to closure including all related change requests. The closure of the problems is accepted by the relevant stakeholders.
Linked Knowledge Nuggets: arrow_forward "Problem monitoring and reporting – Leveraging ALM tools for effective tracking"
personAuthor: Process Fellows
Problem status reports are often generated automatically by Application Lifecycle Management (ALM) tools. These reports are produced on a regular basis to support consistent tracking and reporting of open issues. They serve as a basis for initiating corrective actions—especially when problem trends show no improvement over time.
Recommended use of reports:
Reports should not only reflect the current status but also trigger action. For example, if the number of unresolved issues remains high or increases, this should prompt further analysis and corrective action.
Exemplary key metrics to monitor:
Current problem status distribution:
Number of problems per status (e.g., open, in progress, resolved, closed).
Overdue and aging issues:
Identification of problems that exceed their expected resolution time, including age analysis.
Problem categorization:
Source of problem reports (e.g., internal vs. customer-reported).
Distribution by component or subsystem.
Inflow vs. outflow trends:
Number of new problems reported per calendar week.
Number of problems resolved in the same period.
Severity-based breakdown:
Reports should differentiate by severity level.
For instance, a backlog of minor issues may be acceptable, whereas unresolved critical or showstopper issues require immediate attention.
BP7
Report the status of problem resolution activities. (
O5 )
Collect and analyze problem resolution management data, identify trends, and initiate related actions. Regularly report the results of data analysis, the identified trends and the status of problem resolution activities to the affected parties. Note 6: Collected data may contain information about where the problems occurred, how and when they were found, what their impacts were, etc.
Linked Knowledge Nuggets: arrow_forward "Problem monitoring and reporting – Leveraging ALM tools for effective tracking"
personAuthor: Process Fellows
Problem status reports are often generated automatically by Application Lifecycle Management (ALM) tools. These reports are produced on a regular basis to support consistent tracking and reporting of open issues. They serve as a basis for initiating corrective actions—especially when problem trends show no improvement over time.
Recommended use of reports:
Reports should not only reflect the current status but also trigger action. For example, if the number of unresolved issues remains high or increases, this should prompt further analysis and corrective action.
Exemplary key metrics to monitor:
Current problem status distribution:
Number of problems per status (e.g., open, in progress, resolved, closed).
Overdue and aging issues:
Identification of problems that exceed their expected resolution time, including age analysis.
Problem categorization:
Source of problem reports (e.g., internal vs. customer-reported).
Distribution by component or subsystem.
Inflow vs. outflow trends:
Number of new problems reported per calendar week.
Number of problems resolved in the same period.
Severity-based breakdown:
Reports should differentiate by severity level.
For instance, a backlog of minor issues may be acceptable, whereas unresolved critical or showstopper issues require immediate attention.
# OUTPUT INFORMATION ITEMS
13-07
Problem (
O1, O2, O3, O4 )
Description of an issue.Identifies:
Submitter
Version it was identified
Classification, for example criticality, urgency or relevance
(Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) phase in which problem is recorded
Owner
Status
Technical root cause
Potential effects on other (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.)
Expected closure date
Includes:
Identification
References to other affected domains, subprojects or programs
Relationships to dependencies like changes preventive (Measure = An activity to achieve a certain intent.) or other problems
Used by these processes:
SUP.9 Problem Resolution Management
15-55
Problem analysis evidence (
O2 )
Elements and documents proving a problem analysis is performed.Identifies:
Analyst and owner
Affected and involved parties
Context and root cause of the problem
Analysis results and summary
Potential impact, for example as severity or cost calculation
SUP.9
Problem Resolution Management
