Access to the software requirements or software user stories, software acceptance criteria, software use cases, software functional specifications, software behaviors, software feature descriptions, or software tickets

Demonstrated the software capability definition and software testing criteria. SWEHB emphasizes complete, correct, validated SRS content as the foundation for safe, verifiable software; early clarity prevents costly downstream defects and safety gaps.

Access to the System/Software requirements traceability data

Bi‑directional traceability is required to prove every design, code, and test artifact maps to a validated system need—preventing orphan functionality and ensuring hazards are controlled.

Access to the hazard control software requirements traceability data

Hazard controls must trace explicitly from hazard analysis to software requirements and back to verification evidence to avoid missing or partial mitigations.

Explanation on software safety constraints and assumptions

Documented constraints and assumptions prevent hidden coupling and incorrect operating expectations—frequent root causes in lessons learned for hazardous behavior.

Access to the software requirements analysis results

Structured requirements analysis (ambiguity checks, safety impacts, HSI considerations) provides objective evidence that requirements are testable, feasible, and complete before design.

Access to the software design

Architecture/design descriptions enable validation of partitioning, redundancy, timing, and safety mechanisms; undocumented design is a recurring integration‑failure source in SWEHB.

Explanation on software fault containment and management approach

A clear FDIR strategy limits fault propagation, preserves redundancy, and supports safe recovery for safety‑critical functions.

Access to the software design analysis results

Design reviews/analyses expose interface risks, safety gaps, and performance limits early, reducing costly rework during integration/test.

Access to the Interface Control Documents (ICDs) for software interfaces

ICDs prevent interface mismatch failures—one of the most common categories of integration defects called out in SWEHB checklists.

Access to the data dictionary data

Data dictionaries provide authoritative definitions and units, preventing misinterpretation and unit conversion defects across teams/tools. (SWEHB practice captured in certification checklist.)

Data demonstrating prerequisite checks for all hazardous commands

Prerequisite checks are explicitly required for safety‑critical design to block unsafe command execution unless the system state is validated.

Explanation on how the design and requirements meet safety‑critical requirements

Explicit mapping from safety‑critical requirements to design elements verifies that every control is implemented and testable—closing common gaps seen in hazard mitigations.

Explanation on how the safety‑critical code is modifiable

Modular, isolated safety‑critical code reduces regression risk during updates and enables focused assurance/maintenance. (Emphasized in SWEHB certification guidance.)

Demonstrate applicable human‑factors design principles in the software

HSI evidence (clear displays, alerts, error tolerance) mitigates operator error and automation surprise—frequent contributors to unsafe states in lessons learned and SWEHB checklists.

Access to the software operational plans or user’s manual

Operational manuals drive correct crew/operator actions; unclear procedures have historically led to unsafe system states—documented guidance is essential.

Explanation of the Fault Tolerance approach used in the design

Development evidence must confirm the implemented redundancy, monitoring, and recovery match the approved design/FDIR strategy.

Access to the source code

Assurance/IV&V require code access to assess correctness, safety patterns, and compliance; “code is the design” for verification in SWEHB practice.

Approval data for all AI uses in flight software before deployment

The human‑rated certification checklist in SWEHB requires governance of novel tech; AI decisions must be bounded, transparent, and verified before mission use.

Demonstrate correct AI confidence levels for critical decisions/predictions

Accurate confidence cues preserve appropriate human trust; misleading confidence can induce hazardous operator actions (SWEHB human‑rated checklist).

Demonstrate AI transparency/accountability in critical flight software

Transparency and auditable behavior enable assurance teams to verify AI outputs, edge cases, and failure handling consistent with safety requirements (SWEHB PAT guidance).

Access to defect reports, anomaly logs, and residual risk acceptance

Defect trends and residual‑risk approvals provide readiness evidence and ensure risks are visible and accepted prior to flight (SWEHB PAT‑082).

Access to tailoring/waiver/deviation and TBR/TBD/FWD closures

Tailoring/waiver records show what SWEHB/NPR expectations were modified and how verification gaps were closed—preventing undocumented process escapes.

Evidence that approved processes were followed during development

SWEHB lessons emphasize objective evidence (reviews, audits, checklists) to confirm disciplined execution—avoiding “process‑on‑paper” failures.

Evidence of closure of peer review/inspection findings

Peer reviews are high‑value defect prevention in SWEHB; closure evidence ensures findings are resolved, not deferred into flight risk.

Evidence of qualification/pedigree of reused/third‑party software

SWEHB certification content calls for assessing provenance, constraints, known defects, and verification completeness to control integration risk.

Certification process for models & simulations used to qualify flight software

SWEHB requires validated/accredited models/sims for qualification; unvalidated M&S can mask defects and create false confidence.

WCET/timing/scheduling evidence (partitioning & multicore interference)

Deterministic timing & schedulability evidence prevent deadline misses and resource starvation—common latent hazards noted in SWEHB certification checklists.

Access to the software test results

Test evidence must trace to requirements and hazards to prove correctness and safety under nominal/off‑nominal conditions (SWEHB).

Access to MC/DC coverage data for safety‑critical components

For safety‑critical logic, MC/DC helps reveal untested decision paths—improving confidence that critical branches cannot hide defects (SWEHB practice).

Static and dynamic analysis approach/results

Static/dynamic analyses expose memory, concurrency, and API defects early, complementing functional tests with deeper correctness checks (SWEHB PAT‑082).

Fault‑injection resilience under worst‑case conditions

Fault‑injection validates robustness of error handling and safe‑state transitions under realistic fault scenarios (SWEHB).

Handling spurious signals and invalid inputs

Defensive input handling and integrity checks are SWEHB safety‑critical design requirements to prevent unsafe behavior from noise or corruption.

Certification of software test environments

Accredited test environments assure fidelity so test results represent flight behavior—preventing false positives/negatives (SWEHB PAT‑082).

Cyclomatic complexity analyses results

Complexity correlates with defect likelihood and test effort; tracking supports risk‑based testing and maintainability (SWEHB checklist).

Issues/anomalies/defects list with unresolved‑item justifications

Residual issues require documented operational mitigations and rationale to ensure informed risk acceptance before flight (SWEHB).

Operational test results & resource margins (CPU/memory/throughput)

Resource margin evidence demonstrates the system sustains mission loads without entering unsafe degraded states (SWEHB).

Access to IV&V reports/findings & IV&V scope understanding

Independent assessment adds rigor and identifies latent risks; scope clarity ensures findings are dispositioned (SWEHB/SMA IV&V discussion).

Hazard analysis, FTA, FMEA

Hazard analyses formally identify software causes/contributions and define controls; they are the backbone for safety‑critical requirements and tests (SWEHB).

AI warnings & recommendations for anomalies

AI components must surface anomaly cues and recommended mitigations in time for operator/software safing to prevent hazard escalation (SWEHB PAT‑082 scope).

Operator Action Validation

Operator action validation ensures human‑software interactions are unambiguous and error‑tolerant—reducing unsafe actions under stress (SWEHB checklist).

Software safing procedures

Safing procedures must reliably place the system into known safe states on detection of hazardous conditions—captured in SWEHB safety‑critical design items.

Access to the software documentation

CM control of documentation prevents divergence between what is built, tested, and flown—frequent contributors to integration defects (SWEHB PAT‑082).

Access to the software change logs

Change history enables traceability and impact assessment for safety‑critical components/interfaces (SWEHB).

Version control, baseline definitions, audit records

Version/baseline and audits ensure the exact tested configuration proceeds to flight and prevent unauthorized changes (SWEHB checklist).

Explanation of the software control sequences

Clear control sequences reduce operator confusion and ensure predictable behavior during time‑critical operations (SWEHB).

Explanation of any software manual safing data/processes

Manual safing provides a human‑initiated fallback when automation fails; procedures must be explicit, tested, and accessible (SWEHB).

Encryption, authentication, secure coding, access control

Security controls protect command authority, data integrity, and system availability—security weaknesses can become safety hazards (SWEHB).

Penetration testing and vulnerability analysis results

Pen/vuln testing finds exploitable weaknesses before flight, supporting remediation and risk reduction (SWEHB checklist practice).