1. Introduction

Software Design Analysis product content.

2. Recommended Content

In software design, software requirements are transformed into the software architecture and then into a detailed software design for each software component.  The software design also includes databases and system interfaces (e.g., hardware, operator/user, software components, and subsystems).  The design addresses software architectural design and software detailed design.  The objective of doing design analysis is to ensure that the design is a correct, accurate, and complete transformation of the software requirements that will meet the operational needs under nominal and off-nominal conditions, introduces no unintended features, and that design choices do not result in unacceptable operational risk. The design should also be created with modifiability and maintainability so future changes can be made quickly without the need for significant redesign changes.

Consider the list below when evaluating the software design:

1. 1. Has the software design been developed at a low enough level for coding?
   2. Is the design complete and does it cover all the approved requirements?
   3. Have complex algorithms been correctly derived, provide the needed behavior under off-nominal conditions and assumed conditions, and is the derivation approach known and understood to support future maintenance?
   4. Examine the design to ensure that it does not introduce any undesirable behaviors or any capabilities, not in the requirements?
   5. Have all requirements sources been considered when developing the design (for example, think about interface control requirements, databases, etc.)?
   6. Have the interfaces with COTS, MOTS, GOTS, and Open Source been designed?
   7. Have all internal and external software interfaces been designed for all (in-scope) interfaces with hardware, user, operator, software, and other systems and are they detailed enough to enable the development of software components that implement the interfaces?
   8. All safety features are in the design (mitigations, controls, barriers, must-work requirements, must-not-work requirements)
   9. Does the design provide the dependability and fault tolerance required by the system, and is the design capable of controlling identified hazards?  Does the design create any hazardous conditions?
   10. Does the design adequately address the identified security requirements both for the system and security risks, including the integration with external components as well as information and data utilized, stored, and transmitted through the system?   
   11. Does the design prevent, control, or mitigate any identified security threats and vulnerabilities? Are any unmitigated threats and vulnerabilities documented and addressed as part of the system and software operations?
   12. Operational scenarios have been considered in the design (for example, use of multiple individual programs to obtain one particular result may not be operationally efficient or reasonable; transfers of data from one program to another should be electronic, etc.).
   13. Have users/operators been consulted during design to identify any potential operational issues?
   14. Maintainability: Has maintainability been considered? Is the design modular? Can additions and changes be made quickly?
   15. Is the design easy to understand?
   16. Is the design unnecessarily complicated?
   17. Is the design adequately documented for usability and maintainability?
   18. Has system performance been considered during design?
   19. Has the level of coupling (interactivity between modules) been kept to a minimum?
   20. Has software planned for reuse and OTS software in the system been examined to see that it meets the requirements and performs appropriately within the required limits for this system?
   21. Does this software introduce any undesirable capabilities or behaviors?
   22. Has the software design been peer reviewed?

3. Resources

3.1 References

3.2 Tools