Certification Readiness Scorecard

​

Purpose and Scope

The Certification Readiness Scorecard is designed for program managers, quality assurance teams, and certification authorities who need to assess:

• Requirements completion — percentage of requirements with proper classification, decomposition, and test coverage
• Risk assessment readiness — percentage of failure modes with Risk Priority Number (RPN) calculations
• Design assurance alignment — compliance with DO-178C, DO-254, ARP 4754A, and ARP 4761 objectives
• Evidence inventory — count and status of certification-critical documents

The scorecard updates live as your project data changes, providing real-time visibility into certification milestones.

​

Readiness Metrics Matrix

The scorecard displays per-standard readiness metrics in a matrix format with color-coded progress indicators: Color Coding:

• ✅ Green (≥80%) — Readiness threshold met
• Orange (50–79%) — In progress; attention needed
• ⚠️ Red (<50%) — Critical gaps; immediate action required
• ❓ Gray (N/A) — Not applicable to this project or not yet populated

​

Metric Definitions

​

Classification %

Definition: Percentage of requirements at a given level that have the classification field populated according to standard-specific taxonomy. Formula: (Requirements with classification value / Total requirements at level) × 100 Example: For DO-254 (hardware), classification includes Safety-Critical (SC), Non-Safety-Critical (NSC), or other designations. In the Aero1 project, 14 of 15 design requirements are classified as SC or NSC → 93.3%. Note: DO-178C shows 0.0% because no software design requirements currently exist in the project (all design requirements have subType=electrical or subType=hardware).

​

Decomposition %

Definition: Percentage of requirements at a parent level that have traced children at the next decomposition level. Formula: (Requirements with parent-child links / Total requirements at level) × 100 Hierarchy: Customer Req → System Req → Design Req → Test Case (each level is one decomposition hop). Example: Of 31 system requirements, 13 decompose to design requirements → 41.9% decomposition coverage. Critical for: ARP 4754A system development assurance, which mandates traceability from customer needs through design and test.

​

Test Coverage %

Definition: Percentage of requirements (typically design and system level) that have at least one linked test case. Formula: (Requirements with linked testCase / Total requirements at level) × 100 Example: Of 15 design requirements in the Aero1 project, 6 have traced test cases → 40% test coverage. Note: Test coverage applies to verification requirements (design level) and validation requirements (customer level). Lower percentages may indicate pending test plan development.

​

RPN Scored %

Definition: Percentage of failure modes in risk analysis (SFMEA/DFMEA) that have a calculated post-mitigation Risk Priority Number (RPN). Formula: (Failure modes with postmitigationRPN value / Total failure modes) × 100 RPN Calculation: Severity (1–5) × Occurrence (1–5) × Detection (1–5) = RPN (1–125). Interpretation:

• High Risk (RPN > 30): Red; requires immediate risk control implementation
• Medium Risk (RPN 11–30): Yellow; requires risk control review
• Low Risk (RPN ≤ 10): Green; acceptable with documented justification

Example: ARP 4761 and MIL-STD-882E show 100% RPN scored, indicating all failure modes in the system and subsystem FMEA have post-mitigation scores.

​

Document Inventory

Definition: Count of specification and analysis documents relevant to each standard. Document Types Include:

• Requirement Specs: Customer Requirement (CUST), System Requirement (SYSREQ), Design Requirement (DESREQ)
• Risk Specs: Functional Hazard Assessment (FHA), System FMEA (SFMEA), Design FMEA (DFMEA), Preliminary System Safety Assessment (PSSA), System Safety Assessment (SSA), Fault Tree Analysis (FTA), Common Cause Analysis (CCA)
• Test Specs: Test Case (TESTCASE), Test Specification (TESTSPEC)
• Compliance Specs: Design Requirements Specification (DRS), Compliance Matrix, Security Threat Assessment, Hazard Tracking

Example: ARP 4761 shows 26 documents: 5 requirement specs + 5 safety assessment documents + 16 component-level DFMEA documents.

​

Standards-Specific Guidance

​

ARP 4754A (System Development Assurance)

Objective: Establish confidence that the system can be developed and maintained according to certification standards. Key Metrics:

• Classification: All requirements must be marked SC (Safety-Critical) or NSC (Non-Safety-Critical)
• Decomposition: All requirements must trace top-to-bottom (customer → system → design → test)
• Test Coverage: All design requirements must have at least one verification test case

Readiness Checklist:

• All 25 customer requirements classified
• All 31 system requirements decompose to design level
• All 15 design requirements trace to test cases
• Design assurance level (DAL A–E) assigned to each system requirement per ARP 4761 failure condition

​

DO-178C (Software Airworthiness)

Objective: Demonstrate that software is developed using processes that prevent unintended functions. Applicable If: Your project includes software design requirements (currently 0 in Aero1). Key Metrics:

• Classification: Software design requirements classified per DAL (A = most critical, E = least critical)
• Decomposition: Software requirements trace to code units and tests
• Test Coverage: 100% structural coverage (MC/DC) required for DAL A/B; statement coverage for DAL C

Status in Aero1: 0 software design requirements. Activate when software components are added to the FCC project.

​

DO-254 (Hardware Design Assurance)

Objective: Establish confidence that hardware design is correct and can be manufactured consistently. Key Metrics:

• Classification: All 15 hardware design requirements marked SC (93.3% = 14 of 15)
• Decomposition: 100% of design requirements trace to characteristics and test cases
• RPN Scored: All failure modes in DFMEA have post-mitigation RPN (100%)

Readiness in Aero1:

• ✅ Classification: 14/15 design requirements are SC; 1 remains unclassified
• ✅ Decomposition: All 15 design requirements link to functions and characteristics
• ✅ RPN Scored: All 260 failure modes in component DFMEA have post-mitigation RPN

​

ARP 4761 (Safety Assessment)

Objective: Demonstrate that hazards and failure conditions are identified and mitigated to acceptable risk levels. Key Metrics:

• RPN Scored: All failure modes must have post-mitigation RPN < acceptable threshold
• Document Inventory: FHA, SFMEA, DFMEA, PSSA, SSA, FTA, CCA completed per standard

Readiness in Aero1:

• ✅ FHA: 6 failure conditions identified (Catastrophic, Hazardous, Major, Minor, No Effect per ARP 4761)
• ✅ SFMEA: System-level analysis complete (66 failure modes, 214 risk controls)
• ✅ DFMEA: Component-level analysis in progress (260 failure modes, 12 DFMEA documents)
• ✅ RPN Scored: 100% of failure modes have post-mitigation RPN

​

DO-160G (Environmental Qualification)

Objective: Demonstrate that hardware can operate reliably in its intended environment (temperature, altitude, vibration, etc.). Key Metrics:

• Test Coverage: Environmental characteristics linked to design requirements and qualification tests
• Evidence: Environmental qualification test reports and environmental category assignments

Status in Aero1: Placeholder documents created (4 specs); environmental qualification test matrix pending.

​

MIL-STD-882E (System Safety)

Objective: Establish a formal system safety program with hazard tracking and risk management. Key Metrics:

• RPN Scored: All hazards tracked with severity, probability, and risk control status
• Document Inventory: HARA (Hazard Analysis and Risk Assessment), Hazard Tracking Matrix

Readiness in Aero1:

• ✅ Hazard Tracking: MIL-STD-882E hazard severity (Critical, Major, Minor, Negligible) mapped to RPN
• ✅ Risk Controls: 214 risk control items tracked across SFMEA and DFMEA
• ✅ RPN: 100% of failure modes scored with post-mitigation RPN

​

DO-326A (Airborne Security)

Objective: Demonstrate that the design is resilient to intentional adversarial acts (cyber threats). Key Metrics:

• SAL Assignment: Each threat assessed with Security Assurance Level (SAL 1–3)
• Evidence: Security threat assessment (STRIDE or equivalent) completed

Status in Aero1: Not yet started. Security threat analysis module awaiting input.

​

Using the Scorecard for Certification Planning

​

Readiness Gate Checklist

Phase 1: Requirements & Hazard Analysis (80% threshold)

• Classification: ≥80% of requirements classified per applicable standards
• Decomposition: ≥80% of requirements traced to next level
• RPN Scored: ≥80% of failure modes have post-mitigation RPN
• Document Inventory: All FHA, SFMEA, PSSA documents drafted

Phase 2: Design & Verification (90% threshold)

• Test Coverage: ≥90% of design requirements have test cases
• Decomposition: 100% of requirements traced end-to-end
• RPN Scored: 100% of failure modes have post-mitigation RPN ≤ acceptable level
• Document Inventory: All DFMEA, test specifications, and compliance matrix completed

Phase 3: Certification Authority Review (100% threshold)

• All metrics at 100% (or documented waivers for N/A categories)
• All certification documents reviewed and approved
• Traceability matrix complete and verified
• Compliance artifacts submitted to certification authority

​

Accessing the Scorecard

​

Sidebar Navigation

From the Polarion home dashboard, click Cert. Readiness in the left sidebar (standard 10-item navigation favorites).

​

Direct URL

Navigate to the Standards Compliance → Certification Readiness Scorecard space page. The scorecard auto-updates every 5 minutes based on live work item queries.

​

Reports Export

The scorecard data can be exported as:

• PDF: For certification authority submission
• Excel: For metrics tracking and trend analysis
• JSON: For integration with external compliance tools

​

Related References

For detailed guidance on individual standards and analysis types, refer to:

• Reference → Enumerations → DAL Levels — Design Assurance Level definitions
• Reference → Risksheet Configurations — FHA, SFMEA, DFMEA setup and column reference
• Reference → Dashboards — Role-specific dashboard views including Safety Engineer, Design Engineer, and Program Manager perspectives
• Reference → Document Fields — Custom field definitions for classification, DAL, and other metadata

Source References (dev)

Code: datasets/sol-aero-ui-walkthrough/summary.md, navigation.md, dashboards/home-dashboard.md, dashboards/role-dashboards.md, dashboards/standards-compliance.md, risksheet-views/risksheet-views.md, work-item-types/data-model.md (0.72) · .polarion/pages/spaces/_default/Standards Compliance Overview/page.xml, Certification Readiness Scorecard/page.xml, Compliance Matrix/page.xml (0.66) · .polarion/pages/spaces/_default/Program Manager Dashboard/page.xml, Safety Engineer Dashboard/page.xml, Design Engineer Dashboard/page.xml, VandV Engineer Dashboard/page.xml, Config Manager Dashboard/page.xml (0.56) · .polarion/pages/spaces/Requirements/Home/page.xml, Design/Home/page.xml, Risks/Home/page.xml, Testing/Home/page.xml, Risks/FMEA Reports/page.xml, Documentation/Home/page.xml, Documentation/Powersheet Help Redirect/page.xml, RiskTemplates/Home/page.xml (0.49) · .polarion/nextedy/sheet-configurations/DO-160G Environmental Qualification.yaml, Component RTM.yaml, Configuration Index.yaml, Design Verification Sheet.yaml, Interface Control Matrix.yaml, Problem Report Tracker.yaml, Process Steps.yaml, Review Action Item Tracker.yaml, SOI Stage Gate Dashboard.yaml, Use Steps Specification.yaml, User Need Validation Sheet.yaml, characteristics.yaml, component-characteristics.yaml, customer-requirements.yaml, design-requirements.yaml, subsystem-functions.yaml, subsystem-verification.yaml, system-elements.yaml, test-verification.yaml (0.48) · .polarion/nextedy/sheet-configurations/DO-178C Objectives Compliance Matrix.yaml (0.47) · .polarion/tracker/fields/complianceObjective-custom-fields.xml (0.45) · .polarion/tracker/fields/classification-enum.xml (0.43) · modules/RiskTemplates/ComplianceTemplate/attachments/risksheet.json (0.43) · .polarion/tracker/fields/complianceObjective-standard-enum.xml, complianceObjective-status-enum.xml, complianceRequirement-complianceStatus-enum.xml, complianceRequirement-evidenceType-enum.xml (0.42)