New in SWEHB

Objective evidence plays a crucial role in ensuring accountability, traceability, and reliability across software assurance and safety activities. It provides documented, unbiased proof that a specific activity has been performed or confirmed by the responsible software assurance/safety personnel — and it’s not just about checking a box. It amplifies the credibility of your processes.

Documenting objective evidence can take multiple forms depending on the activity being verified. Some examples include:

• Audit Records and Checklist Results: Observations, findings, or risks identified, documented in a tracking system, or captured in emails.
• Meeting Records: Attendance lists, meeting minutes, or notes stored in the project repository.
• Status Updates: Memos, emails, or reports confirming an activity took place, supported by summaries or confirmation checklists.
• Reviewed/Witnessed Activities: Signatures on reviewed products or processes to validate completion or compliance.
• Short Summaries: Concise statements that provide insight into specific activities or milestones, such as:
  • Progress on IV&V Program Execution.
  • Percentage of hazards traced to software requirements.

When implemented consistently, objective evidence strengthens your project’s integrity, enhances collaboration, and aligns with the guidelines set forth in Section 8.16 of the handbook. Not only does it enable teams to track progress effectively, but it also instills confidence in the accuracy of assurance efforts.

The bottom line? Every requirement deserves solid, verifiable evidence. By prioritizing documentation, you’re not just managing activities — you’re building trust across the project.

Guidance for the Minimum Recommended Content of the Software Requirements Specification was rewritten and expanded using AI content. This rewrite includes expanded guidance, examples, and new guidance for Software Assurance. PAT-059 - Software Requirements Specification Assessment was updated to coincide with this new guidance.

Guidance for the Minimum Recommended Content of the Software Test Plan was rewritten and expanded using AI content. Due to the breadth of information and examples added, this enhanced guidance has been spread across multiple tabs.

Topic 7.23 - Software Fault Prevention and Tolerance This topic guides developers to reduce the likelihood of software faults pre-flight and to detect/mitigate the effects of software errors should they occur in-flight.  

PLDs, especially FPGAs, are becoming increasingly critical in complex avionics and space systems. Establishing a standardized and scalable approach to their development and assurance will not only improve consistency across NASA projects but also enhance mission safety and reliability. By emphasizing early planning, hazard management, training, cross-center collaboration, and consistent application of best practices, NASA can address current limitations while building a foundation for future advancements.

It includes a checklist, a list of Compliance Data Needs and a Safety Case with guidance. It ensures compliance with applicable safety standards, regulatory requirements (NASA NPR 7150.2D, SSP 50038, FAA, NASA-STD-8739.8B), mission-critical functionality, and stakeholder acceptance of residual risks, demonstrating that the software is safe, reliable, and mission-ready for crewed spaceflight operations.

Contracts must align with safety, reliability, regulatory, and operational readiness requirements to ensure that the software meets the stringent demands of FAA regulations, NASA standards, space system requirements, cybersecurity expectations, and military-grade fault-tolerance protocols.

Each Review Checklist is contained in a PAT (MS Word Document) which may be downloaded and used in your project. Each of the 13 PATs has a table which may be used: 

• to prepare for the review - listing all the documents and expectations that will be covered in the review, 
• in the review - the criteria for successful completion are listed as well as an area to note (Y/N) if the criteria is met, and a Comments cell in the table to record any discussion about the item. 

8.27 - Software Engineering and Software Assurance Checklists - Checklists provide a mechanism to independently evaluate the conformance of software products and processes to applicable requirements, standards, guidelines, plans, and procedures.

8.10 - Facility Software with Safety Considerations - Facility software safety exists to ensure the safe and continuous operation of software associated with ground-based facilities. This topic provides guidance on the Facility Life Cycle, document maturity schedules, milestone entry/exit criteria, and SW Engineering and SA responsibilities. 

Software Assurance is required to perform audits and assessments. Thirty (30) new Process Asset Templates (PATs) (i.e., compliance audit and work product assessment checklists) were created for SA personnel use while performing these activities. Schedules were also created with guidance on when to perform these audits and assessments.

Each Activity page includes links to all related  SWEs, Topics, PATs, and other pages. Links to relevant SPAN pages are also included. 

As new content is added to SWEHB, it will also be added to the appropriate Activity page. This collects all content related to a specific Development or Assurance Activity in a single place. 

The subjects include: 

• A. Software Assurance Planning
• B. Software Assurance Analysis
• C. Software Assurance Static Analysis Tools
• D. Software Assurance Audits
• E. Software Assurance Communications
• F. Software Assurance Product Reviews

This topic is designed to provide a basic knowledge of the implementation and importance of good software assurance and software safety through the use of static code analysis in support of projects and missions.

The new topics discuss considerations that must be taken into account when Artificial intelligence and Machine Learning is used in developing Software Products.