1. Requirements

1.1 Notes

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

1.2 History

1.3 Applicability Across Classes

2. Rationale

Software systems are often designed using existing components from other systems. It is recognized that reusing existing software components can help achieve the resulting system more quickly and at a lower cost. However, for software components to be truly reusable, reusability needs to be part of the planned initial development of those components.

3. Guidance

“’30 Pitfalls for Real-Time Software Developers,’ by David B. Stewart discusses problems faced by real-time developers. Of the problems he considers, the following are especially applicable to safety and reliability: ...Reusing code not designed for reuse. If the code was not designed for reuse, it may have interdependencies with other components. Usually, it will not use abstract data types (if object-oriented) or have a well-defined interface.”

With the focus on software reuse increasing, projects need to plan for future reuse of developed software by specifying requirements that facilitate software reuse in the future.  These requirements enhance the benefits of reuse and address the known pitfalls of reuse where that is possible.  These requirements, which should be captured as early in the life cycle as possible, address development processes as well as project technical requirements and are captured in project documentation such as the software development/management plan for processes, project coding standards, and the requirements document or repository for technical requirements.  The software reuse-related requirements are included as a part of the normal software requirements review process and verification & validation process.

Key focus areas of project reusability requirements support SWE-027 and a general strategy for future product reuse, including:

• Documentation associated with the software’s fulfillment of its purpose (e.g., usage instructions).
• Proprietary rights, usage rights, ownership, warranty, licensing rights, and transfer rights.
• Future support for the software.
• Any documentation to allow the software component to be verified and validated to the same level is required to accept a similar developed software component for its intended use.
• Ability to perform periodic assessments of developer-reported defects to ensure the defects do not impact the reused software components.

If the goal is to reuse a product that will exist in the government inventory, such as the Agency Software Catalog accessible via the NASA Technology Transfer Portal, the following are key items to address in reusability requirements

• Technical information to support the determination of whether the product meets the technical requirements of future projects.
• Supporting documentation and user manuals’ for future projects.
• Products to enable test, operations, and maintenance support and disposal services.
• Assistance or documentation is needed to support future requests for acquiring the product from Government sources.

“Use of ... reused software that is not developed specifically for the safety-critical system can be risky.  The software in this category includes ... previously created software (e.g., from a past project).  It is important to evaluate the differences between how the ... reused software will be used within the new system, and how it was used in previous systems.  The differences in operational constraints or configuration of the software may affect the operation of the ... reused software, sometimes in unexpected ways.”

Given that reused software will likely require software to integrate it into the system under development, reusability requirements need to address any aspects of the developed software that will facilitate or reduce the effort to integrate the reused software components with other parts of the developed system.

Additional considerations when generating reusability requirements include:

• The capture of hazard analyses performed on reused software for assessing the safety aspects of that software for use in safety-critical systems.

  Swerefn
  refnum 276

• Information is needed to integrate the software into a system, such as an interface documentation, industry standards conformance, and how the software interacts within itself (between modules) and with the outside world (its application program interface (API)).

  Swerefn
  refnum 276

• Availability of source to allow future safety analyses to be performed and to better understand how the software works.

  Swerefn
  refnum 276

• Information about the software development process used to create the software, including meeting any specific development standards, development tools used to create and test the software.

  Swerefn
  refnum 276

• Information about the testing process used to verify the software, including types of tests performed, availability of test reports, and any additional information to help future projects gauge the thoroughness of the testing.

  Swerefn
  refnum 276

• Information on defects, including known bugs and unresolved problems, is important to help future users make decisions about reusing the software.

  Swerefn
  refnum 276

• Future use or need for analyses performed on the software.

  Swerefn
  refnum 276

• Documentation of error codes returned by the software, how it can fail (return error code, throw an exception, etc.), and information regarding function checks on input variables for proper range.

  Swerefn
  refnum 276

• Information on the internals of the software, such as the complexity of the various software modules or the interfaces between the modules to support future analyses to be performed on the OTS software.

  Swerefn
  refnum 276

• Information regarding “turning off” any of the functionality in the software component, such as recompiling the source code with defined switches or stubs to remove the extra functionality.

  Swerefn
  refnum 276

• Information on to help developers understand what happens to their developed system if an unneeded function in the reused component is accidentally invoked.

  Swerefn
  refnum 276

• Information on any “back doors” (that could be exploited to create a security problem.)

  Swerefn
  refnum 276

Reusability requirements should address the availability of the following documents for future development projects:

• Design documentation.
• Source code.
• Development tools.
• Configuration files, setup files, etc. needed to configure the development tools.
• User documentation.
• Simulators or models developed for use with the operational software.
• Test software, procedures, reports.
• SA reports.
• Formal inspection reports.

Additional guidance related to reusability may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects. 

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

The NASA Lessons Learned database contains the following lesson learned related to bidirectional traceability:

• Reuse of Analysis Software. Lesson Number 2158

  Swerefn
  refnum 592

  : “When a project plans to reuse existing metrology software for a new application, a thorough independent review of the software and its new interfaces should be conducted."
• Software Design for Maintainability. Lesson Number 838

  Swerefn
  refnum 526

  : ” By designing maintainable software products we can update and enhance fielded software much faster and at a lower cost. The software can be reused, thus alleviating costly update time. Also, any faults found in the software can be easily diagnosed and corrected, reducing downtime and meeting delivery schedules. Software maintainability ensures system availability by reducing system downtime.”

6.2 Other Lessons Learned

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

7. Software Assurance

7.1 Tasking for Software Assurance

1. Confirm that the project has considered reusability for its software development activities.

7.2 Software Assurance Products

• None at this time.

7.3 Metrics

•  # of products submitted for reuse.
• # of developed products submitted for reuse vs. total # of developed products.
•   # of developed products entered in NASA Internal Sharing & Reuse System vs. total # of developed products.
•   # of products submitted for reuse vs. # of products entered into NASA Internal Sharing & Reuse Systems

7.4 Guidance

Determine if: 

1. the project has considered reusability for its software development activities,  and if so,
2. reusability considerations are part of the software planning process, software processes, and software requirements (if needed). 

Assess during the software life-cycle development process if any of the software products should or could be provided to other software development activities.

Check to see if the identified software reusable products are listed on the Internal Software Reuse List site located at https://nen.nasa.gov/web/software/reuse-list (NASA only access) and that if any products are identified as reusable, they are put on the list.

Determine if NASA has the proper ownership rights.  All contributors to the software product should be listed with the product. Also, make sure that the Civil Servant point of contact (POC) knows if the software component or software product uses and or contains any commercial software components or any open source software components. Before any software can be shared, the Civil Servant POC has to have a list of all contributors to the software product (SWE-217 ).

If NASA Civil Servants developed the software and the software does not include any open source or commercial software, the software can be shared.

If a contractor helped develop the software, then contact your legal office about the rights to the software.

Ensure that Proprietary rights, usage rights, ownership, warranty, licensing rights, and transfer rights have been addressed for the software components being shared. (see SWE-027 ).

To avoid software license issues associated with sharing software, make sure that the Government has clear rights in the software, a Government purpose license, or other appropriate license or permission from third-party owners before providing the software for internal NASA software sharing or reuse.

If in doubt, contact your Center’s Legal office.

Reusability requirements should address the availability of the following documents for future development projects:

• Design documentation.
• Source code.
• Development tools.
• Configuration files, setup files, etc. needed to configure the development tools.
• User documentation.
• Simulators or models developed for use with the operational software.
• Test software, procedures, reports.
• SA reports.
• Formal inspection reports.

For any third party or re-used software, assess the software plans to ensure the conditions regarding the disclosure,  identification, and use of the software have been identified.  This includes the identification of the SLOCs for the re-used software in the software development plan.