Invalid license: Your evaluation license of Refined expired.
bannerd


Renew your license to continue

Your evaluation license of Visibility for Confluence expired. Please use the Buy button to purchase a new license.

SWE-153 - ETA Define Document Content
This page contains macros or features from a plugin which requires a valid license.

You will need to contact your administrator.

1. Requirements

2.1.5.12 The designated ETA(s) shall define the content requirements for software documents or records.

1.1 Notes

The recommended practices and guidelines for the content of different types of software activities (whether stand-alone or condensed into one or more project level or software documents or electronic files) are defined in NASA-HDBK-2203. The Center defined content should address prescribed content, format, maintenance instructions, and submittal requirements for all software related records. The designated TA for software approves the required software content for projects within their scope of authority. Electronic submission of data deliverables is preferred. “Software records should be in accordance with NPR 7120.5, NPD 2810.1, NASA Information Security Policy, NPD 2800.1, and NPR 2810.1.”

1.2 History

SWE-153 - Last used in rev NPR 7150.2D

RevSWE Statement
A


Difference between A and B

NEW

B

2.1.3.14 The designated Engineering Technical Authority(s) shall define the content requirements for software documents or records. 

Difference between B and C

No Change

C

2.1.5.14 The designated Engineering Technical Authority(s) shall define the content requirements for software documents or records.

Difference between C and DEditorial fix for ETA(s)
D

2.1.5.12 The designated ETA(s) shall define the content requirements for software documents or records.





Renew your license to continue

Your evaluation license of Visibility for Confluence expired. Please use the Buy button to purchase a new license.

2. Rationale

Software development requires documentation and implementation. Software development activities require decisions and work results (e.g., requirements, design, the outcome of reviews, etc.) to be captured as building blocks throughout the software life cycle. Software developers and software acquisitions need to know what documentation expectations exist for a development project.  Having defined and approved content descriptions for project documentation allows these needs and more to be met.

3. Guidance

3.1 Document Content

Typically, software documentation content is defined in a Center data requirements management system or equivalent.  The Engineering Office of Primary Responsibility (OPR) is responsible for approving any proposed tailoring of that defined content.  If the content required for the software documentation is the same as the defined content in the Center data requirements, then the ETA job is easy. 

The ETA on a project coordinates with the Engineering Office of Primary Responsibility (OPR) and the software engineering organizations to ensure modifications to the documentation content are acceptable.  The policy for Center-wide data management is provided in NPR 7123.1 041, Systems Engineering Processes, and data management implementation guidance for programs/projects is documented in Center Data Management Guidance.

Topic 7.18 - Documentation Guidance in this Handbook provides a minimum set of contents for software project documentation at the Agency level.  The designated ETAs at each Center can choose to use this minimum content “as is” or use it to define a set of Center documentation descriptions that are specific to the software projects at that Center. See also 8.16 - SA Products

Center-specific, ETA-approved documentation descriptions for software-related records include the following basic elements:

  • Specific content – list and description of expected content; topics with descriptions of material and information to be addressed and included in the document.
  • Content format – format of specified content within the document itself; the structure of the document; document layout.
  • Maintenance instructions – guidelines for when (frequency, criteria) and how the document is to be updated, revised, and kept current with project progress and activities; may include recommendations regarding who is to perform the maintenance activities.
  • Submittal requirements – guidance for the delivery of a document to NASA (for contracted software development efforts) or project personnel such as management and peers, including delivery frequency, format (electronic is preferred), instructions for placement into electronic repositories, etc.

Electronic submission of data deliverables is preferred, so the defined content, format, maintenance, and submittal requirements defined by the ETA are to encourage electronic delivery.

3.2 Document Format 

Documentation content can be specified as a set of templates, data item descriptions (DIDs), database forms, or any other format that can be accessed and used by Center projects as well as added to subcontractor software development agreements by acquisition personnel.

The approved documentation guidance is kept in a Center-level repository for ease of access by Center projects and acquisition personnel. Center-specific guidance and resources, such as templates, are typically available in Center Process Asset Libraries (PALs).  

Center documentation guidance may also be submitted for addition to the Software Processes Across NASA (SPAN) repository.  NASA-specific documentation templates, examples, checklists, and more are available in SPAN, accessible to NASA users from the SPAN tab in this Handbook.

3.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.4 Center Process Asset Libraries

SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki  197

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

No additional guidance is available for small projects. 

5. Resources

5.1 References

Renew your license to continue

Your evaluation license has expired. Contact your administrator to renew your Reporting for Confluence license.

Renew your license to continue

Your evaluation license of Visibility for Confluence expired. Please use the Buy button to purchase a new license.

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

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.


  • No labels