1. Requirements

3.2.1 The project shall document and maintain the software design.

1.1 Notes

The requirement for the content of a Software Design Description document and an interface design description document are defined in Chapter 5 [of NPR 7150.2, NASA Software Engineering Requirements, section 5.2.3] as applicable by software classification.

1.2 Applicability Across Classes

Classes F and G are labeled with "X (not OTS)." This means that this requirement does not apply to off-the-shelf software for these classes.

2. Rationale

The software design creates the road map from which the software is coded. Once the requirements for the software are defined, they need to be divided into functional components that can be implemented ("coded") separately, yet work together to fulfill the goals and needs for which the software is being written. The software design defines how to segment the software into components and units, which are useful for modularizing like functionality, reuse, etc. "The process of design provides the structure for converting the requirements into the final code. Where the requirements state what must be done, the design provides how it will be done." ²⁷⁶

The goal is to create "a meaningful engineering representation of something that is to be built...a higher-level interpretation of what will actually be implemented in the source code." ²⁷⁶ This representation, which traces back to the requirements, is the software design.

Per NPR 7150.2, "Software design is the process of defining the software architecture, components, modules, interfaces, and data for a software system to satisfy specified requirements. The software architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. The software architectural design is concerned with creating a strong overall structure for software entities that fulfill allocated system and software-level requirements... Detailed design further refines the design into lower-level entities that permit the implementation by coding in a programming language."

Maintaining the software design (e.g., keeping it current with requirements changes or updated as design decisions are made) is important because the resulting software product reflects what is described in the software design. If that design is not current with the latest requirements or design decisions, the resulting product will be less likely to meet customer expectations. Maintaining design documentation is also important for future maintenance of the operational software because maintenance personnel will use the design documentation to diagnose problems, drive solutions, and figure out how to add new features and functionality. 

3. Guidance

Per NPR 7150.2, "Typical views captured in an architectural design include the decomposition of the software subsystem into design entities, computer software configuration items (CSCI), definitions of external and internal interfaces, dependency relationships among entities and system resources, and finite state machines. ...Typical attributes that are documented for lower-level entities include: identifier, type, purpose, function, constraints, subordinates, dependencies, interface, resources, processing, and data. Rigorous specification languages, graphical representations, and related tools have been developed to support the evaluation of critical properties at the design level. Projects are encouraged to take advantage of these improved design techniques to prevent and eliminate errors as early in the life cycle as possible." Projects can take advantage of existing designs when a similar project has already been completed, use frameworks which provide a base infrastructure on which to build, or be auto-coded using advanced design tools.

Guidance for the content of the documents that capture software design, the Software Design Description (SDD) (SWE-111) and the Interface Design Description (IDD) (SWE-112), are found in other sections of this handbook.

The following roles may be involved in defining, documenting, and maintaining software design:

• Software Lead.
• Software engineers.
• Systems engineers.
• Software architects.

Capturing the software design

The software design consists of architectural design (SWE-057) and detailed design (SWE-058). When capturing software design, consider the following:

• Use a defined methodology. such as structured analysis and design, object-oriented analysis and design, model-based development, as appropriate for the software being developed
• Capture the reasoning behind design decisions (to support future design changes and maintenance). ²⁷⁶
• Document reuse plans. ⁰⁴⁷
• Capture a completed definition of the software architecture ²⁷³ (see also Topic 7.07 - Software Architecture Description).
• Develop a preliminary database design description, as applicable. ²⁷³
• Document the selected operating system and development language. ²⁷⁶
• Trace software requirements into the design, as well as tracing the design back to requirements (i.e., bidirectional).
• Define and document the functional interfaces between all components. ²⁷⁶
• Identify and document shared data within the software. ²⁷⁶
• Capture the design in a manner that is maintainable (the design needs to be updated as it matures during development and changes through product maintenance efforts).
• Identify software safety design features and methods used to implement the software safety requirements. ²⁷¹
• Capture the IT security features. ⁰⁷²
• Capture each software subsystem's "software classification (per NPR 7150.2), its safety classification (per NASA-STD-8719.13B, NASA Software Safety Guidebook), the rationale for the classifications" ⁰⁷³; a matrix could be used to capture this information
• Consider the "Design verification approach, e.g., prototyping, inspection, peer review." ⁰⁷³

Information sources

While the software design is based primarily on the software requirements, the following documents may also influence the software design. As applicable, these documents need to be considered as sources of reasons for design decisions:

• Operational concepts and scenarios. ⁰⁰¹
• Trade studies. ⁰⁰¹
• System and hardware requirements. ⁰⁰¹
• Processor and communication specifications. ⁰⁰¹
• Hardware design documents, including interface control documents (ICDs) ⁰⁰¹
• Software requirements rationale.
• Design standards.
• Design selection criteria (to help choose a design or design element from multiple options).
• "Sources for design concepts include, but are not limited to, customer input, brainstorming, collective experience and supplier knowledge." ⁰⁰¹

Useful Methods and Techniques

The following methods and techniques may be helpful when documenting and maintaining the software design:

• Structured analysis and design. ²⁷⁶
• Formal methods and model-based development. ²⁷⁶
• Functional decomposition and object-oriented design, including the use of design diagrams, structure charts, and associated documentation. ⁰⁴⁷
• Design walk-throughs and peer reviews.
• Design inspections. ⁰⁴⁷
• Reuse verification ("determining which of the existing software components specified in the reuse proposal should be integrated into the new system design"). ⁰⁴⁷
• Prototyping and demonstrations.
• Performance modeling. ⁰⁴⁷
• Entity relationship models. ¹⁵⁷
• Design patterns. ¹⁵⁷

General guidance

Some general guidance to follow when capturing and maintaining the software design includes:

• Include a legend for any diagrams that assign specific meaning to shapes, colors, line styles, etc.
• Have the documented design and its updates reviewed at key life-cycle milestone reviews (e.g., Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness Review (TRR)).
• Have the documented design reviewed after it has been updated at any time in the life cycle.
• Include software safety personnel in the design review process.
• Update the requirements as design decisions are made, including adding requirements derived from design decisions.
• Keep the design current with changes to the requirements.
• Perform software peer reviews/inspections (SWE-087) of the design prior to moving to implementation (coding), as applicable.

The NASA Software Architecture Review Board ³²³, a software engineering sub-community of practice, is a good resource of software design information including sample documents, reference documents, and expert contacts.

Additionally, guidance related to software design may be found in Topic 7.07 - Software Architecture Description and the following related requirements in this handbook:

4. Small Projects

Projects with limited personnel or budgets may consider capturing the software design using existing design tools, if they are appropriate for the design effort. Additionally, teams can consider the use of software design document templates from the local Center PAL, modifying them as appropriate for the current software design effort. Projects can also take advantage of existing designs when a similar project has already been completed.

5. Resources

5.1 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

The NASA Lesson Learned database contains the following lessons learned related to software design:

• Preliminary Design Review. Lesson Learned 0655: By not holding a PDR "one or a number of potential problems which could result in an adverse impact on the system, subsystem, and/or project might not be identified in a timely manner. This oversight might later result in a condition having a significant effect on quality, reliability, capability, schedule, and/or cost...Conduct a formal Preliminary Design Review (PDR) at the system and subsystem levels prior to the start of subsystem detail design, to assure that the proposed design and associated implementation approach will satisfy the system and subsystem functional requirements." ⁵¹⁴

• Critical Design Review for Unmanned Missions. Lesson Learned 0657: "In the absence of a CDR, potential problems with adverse impacts on the subsystem, system, or project may not be identified in a timely manner. This oversight may later result in a condition having a significant effect on quality, reliability, capability, schedule, or cost." ⁵¹⁵

• Lessons Learned From Flights of "Off the Shelf" Aviation Navigation Units on the Space Shuttle, GPS (Importance of Accurate Interface Control Document.) Lesson Learned 1370: "If the integrator and user do not have access to firmware and firmware requirements, the ICD may be the only written source of information on unit parameters. Developers of software that will interface with the unit must examine the ICD closely. .... An inaccurate ICD will lead to software and procedural issues that will have to be addressed before a system can be certified as operational. An accurate ICD is also needed for instrumentation port data that is critical during the test and verification phase of a project...Short development schedules may result in changes to the ICD while host vehicle software requirements are being defined and software is in development and test. A disciplined process of checks must be in place to ensure that the ICD and software requirements for units that interface with the [hardware and instruments] are consistent. Individuals who have knowledge of both [hardware] requirements and requirements for other interfacing units must be able to communicate and be involved in any changes made to the ICD." ⁵⁵¹

• MER Spirit Flash Memory Anomaly (2004). Lesson Learned 1483: "Shortly after the commencement of science activities on Mars, an MER rover lost the ability to execute any task that requested memory from the flight computer. The cause was incorrect configuration parameters in two operating system software modules that control the storage of files in system memory and flash memory. Seven recommendations cover enforcing design guidelines for COTS software, verifying assumptions about software behavior, maintaining a list of lower priority action items, testing flight software internal functions, creating a comprehensive suite of tests and automated analysis tools, providing downlinked data on system resources, and avoiding the problematic file system and complex directory structure." ⁵⁵⁷

• NASA Study of Flight Software Complexity. Lesson Learned 2050: "Flight software development problems led NASA to study the factors that have led to the accelerating growth in flight software size and complexity. The March 2009 report on the NASA Study on Flight Software Complexity contains recommendations in the areas of systems engineering, software architecture, testing, and project management." ⁵⁷¹