Design of XXX component of XXX software

Doc # Version: 2013 Page 1 / 4

Thank-you for downloading the

Software Detailed Design Template!

More templates to download on the:

Templates Repository for Software

Development Process (click here)
Or paste the link below in your browser address bar:
http://blog.cm-dm.com/pages/Software-Development-Process-templates

This work is licensed under the:

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France
License: http://creativecommons.org/licenses/by-nc-nd/3.0/fr/

Waiver:
You can freely download and fill the templates of blog.cm-dm.com, to
produce technical documentation. The documents produced by filling the
templates are outside the scope of the license. However, the modification of
templates to produce new templates is in the scope of the license and is not
allowed by this license.

To be compliant with the license, I suggest you to keep the following

sentence at least once in the templates you store, or use, or
distribute:
This Template is the property of Cyrille Michaud License terms: see
http://blog.cm-dm.com/post/2011/11/04/License

Who am I? See my linkedin profile:

http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5

You can remove this first page when you’ve read it and acknowledged it!

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Design of XXX component of XXX software

Doc # Version: 2013 Page 2 / 4

TABLE OF CONTENTS
1 Introduction 2
1.1 Document overview 2
1.2 References 2
1.2.1 Project References 2
1.2.2 Standard and regulatory References 2
2 Software Architecture overview 3
3 Software design description 3
3.1 Component 1 3
3.1.1 Component interfaces 3
3.1.2 Component design description 3
3.1.3 Workflows and algorithms 4
3.1.4 Software requirements mapping 4
3.2 Component 2 4
3.3 Component 3 4
4 SOUP identification 4
5 Critical Requirements 4

1 Introduction

You may have all the description of the design of your software:
 Either in a single instance of this document
 Or have the design of each component/package/element in many instances of this
document.
This is your choice, which depends on the size of your software.

1.1 Document overview

This document describes the design of XXX component/package/element of XXX device, part of
XXX software development project.

1.2 References

1.2.1 Project References

# Document Identifier Document Title

[R1] ID Add your documents references.
One line per document

1.2.2 Standard and regulatory References

# Document Identifier Document Title

[STD1] Add your documents references.
One line per document

Add the standard references to the table above. It may include ISO 14971, ISO 13485, IEC/TR
80002-1, IEC 62304, amongst others.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Design of XXX component of XXX software

Doc # Version: 2013 Page 3 / 4

2 Software Architecture overview

Describe here the top-level software components and their interactions/relationships.
Use UML package diagrams and/or layer diagrams and/or interface diagrams.
Describe also the operating systems on which the software runs.

You may reference the system architecture document, if you have one in your project, which
already explains the software architecture.

3 Software design description

If you have a single design document, describe each top-level package/component of your
software, and if necessary sub-components/sub packages.
 Single instance of design document
o Top-level-component #1  described in section 3.1
 Sub-component #1  described in section 3.1.1
 Sub-component #2  described in section 3.1.2
 And so on…
o Top-level-component #2  described in section 3.2
 …
o Top-level-component #1  described in section 3.3
 …

If you decide to have one design document for each top-level package/component, describe the
content (sub components, sub packages) of each top-level package/component.
The top-level components shall then be described in the system architecture document
 Top-level-component #1  described in instance #1 of SDD document
o Sub-component #1  described in section 3.1
o Sub-component #2  described in section 3.2
o And so on…
 Top-level-component #2  described in instance #2 of SDD document
o …
 Top-level-component #3  described in instance #3 of SDD document
o …

Use Class diagrams, Collaboration / sequence diagrams, Deployment diagrams to illustrate your
description.

3.1 Component 1
Describe the component with the structuration relevant to the technology you use.
Below are examples of sub-sections to describe components.
If you’re in class C, have a look at 5.5.4 of IEC 62304.

3.1.1 Component interfaces

Describe the interfaces of the component and input output data

3.1.2 Component design description

Describe the design of the component, Use package diagrams and/or class diagrams to show the
links between sub-components/sub-packages and or classes inside the component.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Design of XXX component of XXX software

Doc # Version: 2013 Page 4 / 4

3.1.3 Workflows and algorithms

Use collaboration diagrams and/or sequence diagrams to show the workflows of
components/packages/classes inside the component.
Describe algorithms, if possible. An algorithm may be described outside this document, in this
case, add the reference to that document.

3.1.4 Software requirements mapping

Class C software only, list the SRS requirements handled by this component

3.2 Component 2
Repeat the pattern for each component.

3.3 Component 3
Repeat the pattern for each component.

4 SOUP identification
Add the list of SOUP used in software. Example:
SOUP libraries used in XXX are the following:
 foo.jar/foo.so/foo.dll, version id, download URL, License type, requirements traceability
 bar.jar/bar.so/bar.dll, version id, download URL, License type, requirements traceability

Caution: if SRS requirements are handled by SOUP, then traceability between SOUP and SRS
requirements shall be described here.

5 Critical Requirements
If requirement were tagged as critical in the SRS, add here the traceability between these
requirements and the components described in this document. Critical requirements may be
those added after risk analysis.

Requirement ID Requirement title Component Comment

REQ-001 Software shall have Main window Widget added in the
an abort button window layout
Main window Controller aborts the
controller operation

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License