bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin


Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned


Div
idtabs-1

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.


applicable
f*
g*
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnsc0
dsc1
ensc0



Div
idtabs-2

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

sweref
276
276

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

sweref
276
276
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. 


Div
idtabs-3

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

sweref
323
323
, a software engineering sub-community of practice, is a good resource of software design information including sample documents, reference documents, and expert contacts.


Note

Consult Center Process Asset Libraries (PALs) for Center-specific guidance, templates, and examples related to documenting the software design.


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


SWE-057

Software Architecture

SWE-058

Detailed Design

SWE-111

Software Design Description



Div
idtabs-4

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.


Div
idtabs-5

5. Resources


refstable

toolstable


Div
idtabs-6

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