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

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

  sweref
  276 276

• Document reuse plans.

  sweref
  047 047

• Capture a completed definition of the software architecture

  sweref
  273 273

  (see also Topic 7.7 07 - Software Architecture Description).
• Develop a preliminary database design description, as applicable.

  sweref
  273 273

• Document the selected operating system and development language.

  sweref
  276 276

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

  sweref
  276 276

• Identify and document shared data within the software.

  sweref
  276 276

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

  sweref
  271 271

• Capture the IT security features.

  sweref
  072 072

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

  sweref
  073 073

  ; a matrix could be used to capture this information
• Consider the "Design verification approach, e.g., prototyping, inspection, peer review."

  sweref
  073 073

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.

  sweref
  001 001

• Trade studies.

  sweref
  001 001

• System and hardware requirements.

  sweref
  001 001

• Processor and communication specifications.

  sweref
  001 001

• Hardware design documents, including interface control documents (ICDs)

  sweref
  001 001

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

  sweref
  001 001

Useful Methods and Techniques

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

• Structured analysis and design.

  sweref
  276 276

• Formal methods and model-based development.

  sweref
  276 276

• Functional decomposition and object-oriented design, including the use of design diagrams, structure charts, and associated documentation.

  sweref
  047 047

• Design walk-throughs and peer reviews.
• Design inspections.

  sweref
  047 047

• Reuse verification ("determining which of the existing software components specified in the reuse proposal should be integrated into the new system design").

  sweref
  047 047

• Prototyping and demonstrations.
• Performance modeling.

  sweref
  047 047

• Entity relationship models.

  sweref
  157 157

• Design patterns.

  sweref
  157 157

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

Additionally, guidance related to software design may be found in Topic 7.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

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

  sweref
  514 514

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

  sweref
  515 515

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

  sweref
  551 551

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

  sweref
  557 557

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

  sweref
  571 571