Module 1: Some Module Name

Type of Module

Library / Abstract Object / Abstract Data Type / Interface...

Information-Hiding Hierarchy

Hardware-Hiding Module / Behaviour-Hiding Module / Software Decision Module

Hardware-Hiding Module: This module interacts with the hardware and hides the details of the hardware from the rest of the system. You mostly likely be won't be writing such low-level modules.
Behavior-Hiding Module: This module implements something described in the requirements document (SRS). It hides the details of how it works from the rest of the system. If you change the relevant requirements, you will need to change this module in reflection. Software Decision Module: This module contains decision that is not part of the requirements document, but some other consideration to make the software work.

Secrets

What is encapsulated in this module and hidden from the rest of the system?

Services

What can this module do for the rest of the system?

Implemented By

Who is responsible for implementing this module?
This usually means the developer of our software, but in some cases, it may be a third-party library that can be used as-is.

Tips

In this template, we don't write about the details of a module (class methods, calculations, etc.) here in the formal documents. Instead, at the design phase, we would create code files and write the class names, function headers, etc. there. Then we would write formatted comments in the code to explain the above details. This way, the code is the single source of truth for the details of the module. Link back to the SRS for exact calculations when necessary.