The purpose of the software design document is to be the guide for someone who needs to understand the code to maintain it, extend it, or re-use parts of it. While "all of the information" is in the code, the concepts that underlie it are lost in the details. Consider this document a tutorial for your code. While it is true that the reader of the document will be familiar with basic programming and object-oriented concepts, that is all that you can assume. Do not assume a knowledge of the domain of the application. (How good was your understanding when you started the project?) Do not assume an understanding of the platform you are using. You should point the reader to existing tutorial materials, not rewrite them! You should not, however, throw jargon around that will confuse the uninitiated. Consider as a driving use case that you hand this document to a new developer with a specific task to accomplish. Will they have the tools to accomplish it in a reasonable time?
You are more apt to find that graphical represention helps in the architecture and high-level decomposition. Beyond that, you will probably find that text will work fine. If you are using a standard architecture, such as might exist in Unity, you should reference that architecture and potentially include a borrowed figure or two.
Specific elements to be included in the software design document are:
Remember that this is the starting point for the reader of the document. The architecture describes the highest level view of the software system. An architecture description will typically have between 3 and 7 components. This should be the highest level of decomposition that you use to reason about the system. When you are discussing the implications of a design change or how to divide up work, you should be able to easily map that back to the architecture. The architecture is to be documented as a picture with a paragraph explaining the model. Your architecture should translate into the application terms (e.g., MVC is not sufficient). Do not use general terms such as "repository", but rather what data the repository holds.
The next three sections give different views of the model defined in the architecture. The terminology used here is not object-oriented because not all projects are OO. If your project is OO, feel free to use the OO terminology. This is the next level of decomposition from the architecture. It should flow from the architecture and relate the components, but not define any of the components completely. That's what the next two sections do!
Describe the primary modules that you are using and the relationships among them. Whenever you are defining relationships among components, you may find a picture a useful addition to the write-up. The details of the modules are described later. The purpose of this section is to relate them to each other.
If your application uses concurrent processes or multiple threads, explain why they exist and what they are doing. For example, a system with multiple inputs may have different processes monitoring those inputs. Also cover when they are created and destroyed.
Describe all the key data components of the system. Specifically, this is the persistent data -- files that you use or create and databases. The detailed specifications come later; the purpose of this section is again to give a high-level view of what the files are, how they are used, and how they relate to each other. If there are multiple tables in a single database, this should be explicitly covered. If there is no external data associated with your application, this section is not needed.
For each module, you now will describe its specifics, including the interfaces, details of decomposition, and key algorithms. If this is a class, you will define its attributes and their types as well as all of the associated methods. You need to describe what functions the methods are doing and a natural language explanation of the attributes. In addition, if there are identifiable invariants, pre- or post-conditions of the methods, they should be documented here. In addition, this is the place to define any of the key algorithms that you use. If you are using a standard routine or data structure (e.g., a binary tree), you do not need to do more than state that fact. You should be using a document generator like Javadoc. I do not expect anyone to be creating this section manually. A reference to the generated document is sufficient but you should capture a snapshot of the information in case the tool you are using is unavailable.
For any file or database, a complete definition of the format needs to be included. The definition should include both the format and use of each field within the application. If there are constraints on fields, they should be included. The relationship of individual fields are also defined here. If there is no external data associated with your application, this section is not needed. Again a reference to a tool-generated description of a database is sufficient.
This is the place to document any decisions that you made that effected the overall design of the system that you have been capturing on your website. Any dependencies that the application has should be explicitly stated here and the reason for that dependency explained. Decisions about things that you chose not to do are as important as those that you chose to do.
In addition, consider this the repository of any other information that will be helpful to the next developer.
Consider this the one document that survives for the developer. It should include all the istructions that the new developer needs to get started and a pointer to the code repository.