bannerc
SWE-000 - SWE Template

 Content based on NPR7150.2C and NASA-STD-8739.8

 

1. Requirements

0.0.0 The requirement verbatim from the NPR.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

OR, if there are any notes in the NPR, repeat them here verbatim.

1.2 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Sometimes Safety Critical; E - F = Never Safety Critical.

 

2. Rationale

Justification for the requirement if any.

 

3. Guidance

Guidance on how to satisfy the requirement.

 

4. Small Projects

Statement on applicability of the requirement to small projects.

5. Resources

5.1 References

No references have been currently identified for this SWE. If you wish to suggest a reference, please leave a comment below.

5.2 Tools

If there are specific tools relative to this SWE or Topic they will be found in the subsections below. You may also wish to reference the Tools Table in this handbook for an evolving list of tools in use at NASA. Note that this Tools Table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with specific requirements. .

6. Lessons Learned


No lessons learned have currently been identified for this requirement.

6.1 NASA Lessons Learned


Lessons that appear in the NASA LLIS or Center Lessons Learned Databases.

  • Lesson Title in bold. Lesson Number 9999:  567Extract from the lesson. Extract taken which points up the lessons that is appropriate to the SWE or Topic of this page. Add a SWEREF pointing back to the reference for the lesson. 

6.2 Other Lessons Learned (add this category only if appropriate)

Lessons that appear in the sources outside of NASA such as educational sources or industry sources.

  • Lesson Title in bold. Lesson Number 9999:  567 Extract from the lesson. Extract taken which points up the lessons that is appropriate to the SWE or Topic of this page. Add a SWEREF pointing back to the reference for the lesson. 


7. Software Assurance

Error rendering macro 'excerpt-include'

No link could be created for 'T'.

7.1 Tasking for Software Assurance


7.2 Software Assurance Products


Objective Evidence

  • Provide confirmation that Task 1 has been done
 Click here for definition ...

Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing Short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.


7.3 Metrics


7.4 Guidance


  • No labels