bannerd

A. Introduction

B. Institutional Requirements

C. Project Software Requirements

D. Topics

E. Tools, References, and Terms

F. SPAN
(NASA Only)

Style guide for SWEs. May be used as a template. 

SWE Style Guide and Template

1. Requirements

2.1.1.1 The NASA OCE shall lead and maintain a NASA Software Engineering Initiative to advance software engineering practices.

1.1 Notes

The Notes from the SWE in NPR7150.2 are copied here. In "paragraph" style with bullets as necessary. If there are no Notes, the statement below is the only note in this section. 

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

1.2 History

Click here to view the history of this requirement: SWE-050 History

1.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable

2. Rationale

Provide a reason for the SWE in this section. 

3. Guidance

Provide additional guidance for the SWE in this section. 

Use numbering and bullets as necessary.

Graphics may be used also to explain concepts. A copy of the original artwork should be attached to the page so it can be used if the image needs to be revised. 

3.1 Additional sub headings

Use Heading 1 style for the initial heading in the tab. Use Heading 2 style for the next level of subheadings. If a lower heading style is needed, use Heading 3. Try to not have lower heading styles below 3. 


If a summary of referenced SWEs is appropriate, use a simple table of links like the one below. 

SWE-051 - Software Requirements Analysis
SWE-052 - Bidirectional Traceability

4. Small Projects

"No additional guidance is available for small projects."

OR, other statement on applicability of the requirement to small projects.

5. Resources

5.1 References

[Click here to view master references table.]

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

5.2 Tools


Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN). 

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN. 

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool.  The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

No lessons learned have currently been identified for this requirement.

OR, statement of lessons learned applicability is needed. 

6.1 NASA Lessons Learned

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

  • 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. 

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. 

This tab is only appropriate for SWEs having SA tasking. It is not used for Institutional Requirements. 

7. Software Assurance

Error rendering macro 'excerpt-include'

No link could be created for 'SWE-050 - Software Requirements'.

 - gets SWE from tab 1. 

7.1 Tasking for Software Assurance

  1. Tasking for software Assurance goes here. 

7.2 Software Assurance Products

  • The list of SA products goes here


Objective Evidence

Evidence is noted here

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 a 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.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.


7.3 Metrics

  • # of 
  • # of

7.4 Guidance

Software assurance guidance for this SWE goes here. 
  • No labels

0 Comments

Page Editor: Tim Crumbley
NASA Official: Tim Crumbley
Accessibility
NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer
NASA Privacy Statement
______________________________________________________________________________