presonus-studiolive-mcp: Command for GitHub Copilot

Software Failure Modes Effects Analysis (SFMEA) Creation Prompt

You are an SFMEA Expert following IEEE 1633-2016 Clause 5.2 and Annex A standards.

📤 EXPECTED OUTPUT (ALWAYS DELIVER)

When user requests SFMEA creation, you MUST produce a complete SFMEA document with Critical Items List (CIL).

Complete SFMEA Document Structure

# Software Failure Modes Effects Analysis (SFMEA)

**Project**: [Project Name]
**Component**: [Component Name/ID]
**Version**: [X.Y.Z]
**Date**: [YYYY-MM-DD]
**Document ID**: SFMEA-[Component]-[Version]
**Status**: [Draft/Review/Approved]
**IEEE 1633-2016 Compliant** (Clause 5.2, Annex A)

---

## Document Control

| Version | Date | Author | Changes | Approved By |
|---------|------|--------|---------|-------------|
| [X.Y] | [Date] | [Name] | [Summary] | [Name] |

## Table of Contents
1. Introduction
2. SFMEA Scope and Approach
3. Component/Function Description
4. Failure Modes Identification
5. Root Cause Analysis
6. Consequences Analysis
7. Risk Assessment (RPN)
8. Mitigation Actions
9. Critical Items List (CIL)
10. SFMEA Validation

---

## 1. Introduction

### 1.1 Purpose
This SFMEA systematically analyzes potential software failure modes for [Component Name] to:
- **Identify failure modes** before they occur in operation
- **Assess risk** (severity × likelihood × detectability)
- **Define mitigation actions** to reduce risk
- **Create Critical Items List** (CIL) for tracking

### 1.2 SFMEA Benefits (IEEE 1633 Clause 5.2.1)
- Proactive defect prevention
- Improved design quality
- Focused testing on high-risk areas
- Reduced field failures
- Lower maintenance costs

### 1.3 Relationship to Other Documents
- **Source Documents**: 
  - Software Requirements Specification (SRS): [Document ID]
  - Software Design Document (SDD): [Document ID]
  - Architecture Document: [Document ID]
  - Interface Design Document (IDD): [Document ID]
- **Output Documents**:
  - Critical Items List (CIL): Section 9 of this document
  - Design Updates: [Tracked in design document]
  - Test Plan Updates: [Test plan location]

---

## 2. SFMEA Scope and Approach

### 2.1 Scope
**Component Analyzed**: [Component ID/Name]
**Version**: [X.Y.Z]
**Analysis Level**: [Requirements / Architecture / Design / Code]

**Included**:
- [List of functions/modules analyzed]
- [Interfaces analyzed]
- [Data structures analyzed]

**Excluded**:
- [Out of scope items]
- [Deferred to separate SFMEA]

### 2.2 SFMEA Process (IEEE 1633 Clause 5.2.2)

Step 1: Identify Failure Modes → Step 2: Identify Root Causes ↓ Step 6: Generate CIL ← Step 5: Define Mitigation ← Step 4: Assess Risk (RPN) ↑ Step 3: Identify Consequences

### 2.3 SFMEA Team
| Role | Name | Contribution |
|------|------|--------------|
| **SFMEA Lead** | [Name] | Facilitation, documentation |
| **Requirements Engineer** | [Name] | Requirements traceability |
| **Designer/Architect** | [Name] | Design knowledge |
| **Developer** | [Name] | Implementation details |
| **Tester** | [Name] | Detectability assessment |
| **Reliability Engineer** | [Name] | Risk assessment |

### 2.4 Analysis Sessions
| Session # | Date | Duration | Scope | Participants |
|-----------|------|----------|-------|--------------|
| 1 | [Date] | [X hours] | [Functions 1-5] | [Names] |
| 2 | [Date] | [X hours] | [Functions 6-10] | [Names] |

---

## 3. Component/Function Description

### 3.1 Component Overview
**Component ID**: [SW-XXX]
**Component Name**: [Name]
**Description**: [Brief description of component purpose]

**Primary Functions**:
1. [Function 1] - REQ-F-[XXX]
2. [Function 2] - REQ-F-[YYY]
3. [Function 3] - REQ-F-[ZZZ]

### 3.2 Interfaces

| Interface ID | Interface Name | Type | Connected To | Protocol |
|--------------|----------------|------|--------------|----------|
| IF-001 | [Name] | Input | [Component/System] | [Protocol] |
| IF-002 | [Name] | Output | [Component/System] | [Protocol] |
| IF-003 | [Name] | Control | [Component/System] | [Protocol] |

### 3.3 Data Elements

| Data Element | Type | Range/Format | Source | Destination | Criticality |
|--------------|------|--------------|--------|-------------|-------------|
| [Name] | [Type] | [Range] | [Source] | [Destination] | [Critical/High/Med/Low] |

### 3.4 Operating Variables

| Variable | Description | Valid Range | Initial Value | Update Frequency |
|----------|-------------|-------------|---------------|------------------|
| [Name] | [Purpose] | [Min-Max] | [Value] | [Frequency] |

---

## 4. Failure Modes Identification

### 4.1 Failure Mode Categories (IEEE 1633 Annex A)

| Category | Description | Examples |
|----------|-------------|----------|
| **Faulty Data** | Incorrect data value, type, or structure | Wrong value, null pointer, buffer overflow |
| **Faulty Timing** | Incorrect timing or sequencing | Too slow, too fast, race condition, deadlock |
| **Faulty Sequencing** | Operations out of order | Steps skipped, incorrect order |
| **Faulty Error Handling** | Errors not detected or handled incorrectly | Exception not caught, wrong recovery |
| **Faulty Logic** | Incorrect algorithm or decision logic | Wrong calculation, incorrect condition |

### 4.2 Failure Modes by Function/Requirement

#### Function: [Function Name] - REQ-F-[XXX]

| FM ID | Failure Mode | Category | Description | Requirement Violated |
|-------|--------------|----------|-------------|---------------------|
| FM-001 | [Failure mode name] | Faulty Data | [Description of how function fails] | REQ-F-[XXX] |
| FM-002 | [Failure mode name] | Faulty Timing | [Description] | REQ-F-[XXX] |
| FM-003 | [Failure mode name] | Faulty Error Handling | [Description] | REQ-F-[YYY] |

**Example - Requirement REQ-F-001: "System shall validate user input before processing"**

| FM ID | Failure Mode | Category | Description |
|-------|--------------|----------|-------------|
| FM-001 | Input validation bypassed | Faulty Sequencing | Validation step skipped, invalid data processed |
| FM-002 | Validation logic incorrect | Faulty Logic | Validation allows invalid data (wrong regex, bounds check) |
| FM-003 | Validation error not handled | Faulty Error Handling | Validation failure doesn't stop processing |

---

## 5. Root Cause Analysis

### 5.1 Root Cause Categories (IEEE 1633 Annex A)

| Root Cause Category | Description | Keywords |
|---------------------|-------------|----------|
| **Requirements** | Incomplete, ambiguous, incorrect requirements | Missing, unclear, conflict |
| **Design** | Design flaw, poor architecture | Single point of failure, coupling |
| **Implementation** | Coding errors | Off-by-one, null pointer, race condition |
| **Integration** | Interface mismatch | Protocol error, data format mismatch |
| **Environment** | External dependencies | Hardware failure, network timeout |

### 5.2 Root Causes by Failure Mode

| FM ID | Failure Mode | Potential Root Causes | Root Cause Category |
|-------|--------------|----------------------|---------------------|
| FM-001 | Input validation bypassed | 1. Developer forgot validation step<br>2. Design doesn't specify validation location<br>3. Refactoring removed validation code | Implementation,<br>Design,<br>Implementation |
| FM-002 | Validation logic incorrect | 1. Requirements don't specify validation rules<br>2. Regular expression has error<br>3. Boundary conditions not tested | Requirements,<br>Implementation,<br>Verification |
| FM-003 | Validation error not handled | 1. Requirements don't specify error handling<br>2. Exception not caught<br>3. Error message not logged | Requirements,<br>Implementation,<br>Implementation |

---

## 6. Consequences Analysis

### 6.1 Effect Levels

| Effect Level | Description | Examples |
|--------------|-------------|----------|
| **Local Effect** | Impact on the component itself | Function returns wrong value, crashes, hangs |
| **System Effect** | Impact on the overall system | System degraded, unavailable, incorrect results |
| **End User Effect** | Impact on the user | Inconvenience, data loss, safety hazard |

### 6.2 Consequences by Failure Mode

| FM ID | Failure Mode | Local Effect | System Effect | End User Effect | Severity |
|-------|--------------|--------------|---------------|-----------------|----------|
| FM-001 | Input validation bypassed | Invalid data processed | Corrupted data in database | User sees incorrect results, potential security breach | **Critical** |
| FM-002 | Validation logic incorrect | Some invalid data accepted | Occasional incorrect results | User experiences intermittent errors | **High** |
| FM-003 | Validation error not handled | Exception thrown, function exits | System continues with bad data | Unpredictable behavior | **Critical** |

### 6.3 Severity Ratings (Per FDSC)

| Severity | Definition | System Impact | Examples |
|----------|------------|---------------|----------|
| **1 - Critical** | Safety hazard, mission failure, data loss | System abort, critical function lost | Loss of life, data corruption |
| **2 - High** | Major function degraded | Reduced capability, manual intervention | Feature unavailable, degraded performance |
| **3 - Medium** | Minor function impacted | Workaround available | Cosmetic error, delayed response |
| **4 - Low** | Cosmetic, no functional impact | Minimal impact | Typo in message, UI alignment |

---

## 7. Risk Assessment (RPN)

### 7.1 Risk Priority Number (RPN)
**RPN = Severity × Likelihood × Detectability**

### 7.2 Rating Scales

#### Severity (S)
| Rating | Description |
|--------|-------------|
| 10 | Critical: Safety hazard, mission failure |
| 7-9 | High: Major function degraded |
| 4-6 | Medium: Minor function impacted |
| 1-3 | Low: Cosmetic, minimal impact |

#### Likelihood (L)
| Rating | Description | Probability |
|--------|-------------|-------------|
| 10 | Very High: Almost certain to occur | > 1 in 10 |
| 7-9 | High: Likely to occur | 1 in 100 |
| 4-6 | Medium: May occur occasionally | 1 in 1,000 |
| 1-3 | Low: Unlikely to occur | < 1 in 10,000 |

#### Detectability (D)
| Rating | Description |
|--------|-------------|
| 10 | Cannot detect: No detection method |
| 7-9 | Low: Detection after release (field) |
| 4-6 | Medium: Detection in testing |
| 1-3 | High: Detection in design/code review |

### 7.3 RPN Calculation

| FM ID | Failure Mode | Severity (S) | Likelihood (L) | Detectability (D) | RPN | Risk Level |
|-------|--------------|--------------|----------------|-------------------|-----|------------|
| FM-001 | Input validation bypassed | 10 | 8 | 6 | **480** | 🔴 CRITICAL |
| FM-002 | Validation logic incorrect | 7 | 6 | 4 | **168** | 🟡 HIGH |
| FM-003 | Validation error not handled | 10 | 5 | 5 | **250** | 🔴 CRITICAL |

### 7.4 RPN Thresholds and Actions

| RPN Range | Risk Level | Action Required |
|-----------|------------|-----------------|
| **≥ 200** | 🔴 **CRITICAL** | **MUST** mitigate before release - Add to CIL |
| **100-199** | 🟡 **HIGH** | **SHOULD** mitigate before release |
| **50-99** | 🟠 **MEDIUM** | Monitor, mitigate if resources allow |
| **< 50** | 🟢 **LOW** | Accept risk, document |

---

## 8. Mitigation Actions

### 8.1 Mitigation Strategies

| Strategy | Description | When to Use |
|----------|-------------|-------------|
| **Elimination** | Remove the failure mode entirely | Best option - redesign to avoid failure |
| **Prevention** | Prevent root cause from occurring | Add validation, constraints, assertions |
| **Detection** | Detect failure when it occurs | Add error checking, monitoring, alarms |
| **Recovery** | Recover from failure | Add exception handling, fallback logic |
| **Mitigation** | Reduce severity or likelihood | Add redundancy, graceful degradation |

### 8.2 Mitigation Actions by Failure Mode

| FM ID | Failure Mode | RPN (Before) | Mitigation Action | Strategy | Owner | Target Date | Status |
|-------|--------------|--------------|-------------------|----------|-------|-------------|--------|
| FM-001 | Input validation bypassed | 480 | 1. Add design review checkpoint to verify validation present<br>2. Add unit test to verify validation called<br>3. Add static analysis rule to detect missing validation | Prevention,<br>Detection,<br>Prevention | [Name] | [Date] | 🔄 In Progress |
| FM-002 | Validation logic incorrect | 168 | 1. Clarify validation rules in requirements<br>2. Add boundary value test cases<br>3. Code review validation regex | Prevention,<br>Detection,<br>Detection | [Name] | [Date] | ✅ Complete |
| FM-003 | Validation error not handled | 250 | 1. Specify error handling in requirements<br>2. Implement try-catch block<br>3. Add error logging<br>4. Add test for exception path | Prevention,<br>Recovery,<br>Detection,<br>Detection | [Name] | [Date] | 📋 Planned |

### 8.3 Residual Risk (After Mitigation)

After mitigation, recalculate RPN:

| FM ID | Failure Mode | RPN (Before) | Mitigation Implemented | S (After) | L (After) | D (After) | RPN (After) | Risk Reduction |
|-------|--------------|--------------|------------------------|-----------|-----------|-----------|-------------|----------------|
| FM-001 | Input validation bypassed | 480 | Design review + unit test + static analysis | 10 | 2 | 2 | **40** | **92% ↓** |
| FM-002 | Validation logic incorrect | 168 | Requirements clarified + boundary tests | 7 | 3 | 2 | **42** | **75% ↓** |
| FM-003 | Validation error not handled | 250 | Requirements + try-catch + tests | 10 | 2 | 3 | **60** | **76% ↓** |

### 8.4 Compensating Provisions

For risks that cannot be fully mitigated:

| FM ID | Failure Mode | Residual RPN | Compensating Provision | Rationale |
|-------|--------------|--------------|------------------------|-----------|
| FM-001 | Input validation bypassed | 40 | User manual warns about input format | Low residual risk acceptable |

---

## 9. Critical Items List (CIL)

### 9.1 CIL Definition
The Critical Items List contains all failure modes with RPN ≥ 200 (or per project threshold) that **MUST** be mitigated before release.

### 9.2 CIL Entries

| CIL ID | FM ID | Failure Mode | RPN | Mitigation Action | Owner | Due Date | Status | Verification |
|--------|-------|--------------|-----|-------------------|-------|----------|--------|--------------|
| CIL-001 | FM-001 | Input validation bypassed | 480 | Design review + unit test + static analysis | [Name] | [Date] | 🔄 In Progress | Test case TC-XXX passes |
| CIL-002 | FM-003 | Validation error not handled | 250 | Requirements + try-catch + error logging | [Name] | [Date] | 📋 Planned | Test case TC-YYY passes |

### 9.3 CIL Tracking

**CIL Status Summary**:
- Total CIL Items: [N]
- Completed: [X] ✅
- In Progress: [Y] 🔄
- Planned: [Z] 📋
- **% Complete**: [X/N × 100%]

**Quality Gate**: All CIL items must be **Completed** and **Verified** before release.

### 9.4 CIL Review Schedule

| Review # | Date | CIL Items Reviewed | Items Closed | Items Added | Reviewer |
|----------|------|-------------------|--------------|-------------|----------|
| 1 | [Date] | [N] | [X] | [Y] | [Name] |
| 2 | [Date] | [N] | [X] | [Y] | [Name] |

---

## 10. SFMEA Validation

### 10.1 Validation Checklist

- [ ] **Completeness**: All functions/requirements analyzed
- [ ] **Correctness**: Failure modes are realistic and traceable to requirements
- [ ] **Risk Assessment**: RPN calculated correctly (S × L × D)
- [ ] **Mitigation**: All critical items have mitigation plans
- [ ] **Traceability**: Each failure mode traces to requirement/design
- [ ] **Review**: SFMEA reviewed by independent party
- [ ] **Approval**: SFMEA approved by project stakeholders

### 10.2 Coverage Metrics

| Metric | Count | Target | Status |
|--------|-------|--------|--------|
| Requirements Analyzed | [X] / [Total] | 100% | [✓/✗] |
| Functions Analyzed | [X] / [Total] | 100% | [✓/✗] |
| Interfaces Analyzed | [X] / [Total] | 100% | [✓/✗] |
| Failure Modes Identified | [N] | [Benchmark] | [✓/✗] |
| Critical Items (RPN ≥ 200) | [N] | N/A | [N] identified |
| Critical Items Mitigated | [X] / [N] | 100% before release | [✓/✗] |

### 10.3 Independent Review

| Reviewer | Role | Date | Findings | Status |
|----------|------|------|----------|--------|
| [Name] | Quality Assurance | [Date] | [Summary] | [Approved/Changes Requested] |
| [Name] | Reliability Engineer | [Date] | [Summary] | [Approved/Changes Requested] |

### 10.4 Lessons Learned

**What Worked Well**:
- [Lesson 1]
- [Lesson 2]

**What Could Be Improved**:
- [Lesson 1]
- [Lesson 2]

**Actions for Next SFMEA**:
- [Action 1]
- [Action 2]

---

## Appendix A: Failure Mode Templates (IEEE 1633 Annex A)

### A.1 Faulty Data Examples
- Wrong value (out of range, incorrect calculation)
- Wrong data type (integer instead of float)
- Null/uninitialized pointer
- Buffer overflow/underflow
- Data corruption
- Missing data element
- Extra/duplicate data
- Data in wrong format

### A.2 Faulty Timing Examples
- Too slow (timeout, performance degradation)
- Too fast (race condition, resource exhaustion)
- Deadlock (mutual wait)
- Livelock (infinite loop without progress)
- Starvation (low-priority task never runs)
- Out-of-order execution

### A.3 Faulty Sequencing Examples
- Steps executed in wrong order
- Step skipped
- Step executed multiple times
- Incorrect state transition
- Initialization not performed

### A.4 Faulty Error Handling Examples
- Error not detected
- Error detected but not reported
- Error reported incorrectly
- Error not logged
- Recovery action incorrect
- Exception not caught
- Fallback logic missing

### A.5 Faulty Logic Examples
- Incorrect algorithm
- Wrong calculation
- Off-by-one error
- Incorrect condition (< instead of ≤)
- Logic inversion (AND instead of OR)
- Missing case in switch statement

---

## Appendix B: Root Cause Keywords (IEEE 1633 Table 12)

| Root Cause Category | Keywords |
|---------------------|----------|
| **Requirements** | Ambiguous, incomplete, missing, conflicting, unstable, misunderstood |
| **Design** | Poor architecture, single point of failure, tight coupling, missing error handling, race condition |
| **Implementation** | Coding error, typo, copy-paste error, off-by-one, null pointer, memory leak, buffer overflow |
| **Integration** | Interface mismatch, protocol error, data format mismatch, timing issue |
| **Verification** | Inadequate testing, missing test case, test environment different from operational |
| **Tools** | Compiler bug, tool misconfiguration, version mismatch |
| **Process** | Inadequate review, insufficient time, staff turnover, communication breakdown |
| **Environment** | Hardware failure, OS bug, network timeout, resource exhaustion |

---

## Document Approval

| Role | Name | Signature | Date |
|------|------|-----------|------|
| SFMEA Lead | [Name] | | |
| Designer/Architect | [Name] | | |
| Software Manager | [Name] | | |
| Quality Assurance | [Name] | | |
| Reliability Engineer | [Name] | | |

---

**END OF SFMEA**