How to write software development process documents? -- "Document = chicken ribs "?

"Chicken ribs-tasteless, abandon a pity", the software development process documentation encountered the same situation.

At present, agile software development is very popular. Compared with the software development process documentation, agile software development processes pay more attention to operationalProgram.
There are two extremes of software development process documents: first, process documents are strictly required, and process documents are taken as an inevitable output of the development process without considering whether the documents really work, that is, "Excessive documentation ". The second is to abandon the document completely without any record. Excessive documentation deviates from the essence of software development, which can cause a great waste of manpower. Abandoning documents will lead to loss of key information in development, which is not conducive to the maintenance of products in the future.
We need to make a balance between the two. Here we can reference the "20% Law": Record 80% of the content in documents. In this way, the minimum investment is used to obtain the maximum value.
Which of the following items should be recorded in 20% documents?
1. Product Requirement Description.
Undoubtedly, this is the most important piece of information. For Product Requirement Description, you can write two documents: one is the overall requirement description and the other is the feature table document. The functional feature table breaks down the overall requirements to facilitate future tracking of requirements.

2. Software Architecture description, software entities and their interactions.
The overall structure of the system, including the number of entities in the system, the role of each entity, and the interaction between entities. Generally, graphical descriptions are required.

3. Internal program structure, logic module, and interaction.
The division of internal logic modules of software entities, the role of each module, and the interaction mechanism between modules.

4. database design.
Database, expression, and field design.

5. communication protocols.
Description of interactive messages between software entities, such as sip and XML.

6. Key data structure functions.
Key data structure definitions and functions that reflect the logical structure of software entities.

7. complex problem solutions.
To solve complex requirements, multiple software entities or logic modules are required for interaction. These solutions are worth recording and can facilitate subsequent product maintenance.

The document writing time can be flexible and can be carried out during the project development process. If the development progress is very tight, you can also add the document after the development is complete. If you make major changes to the product during maintenance, you must refresh the document in time to keep the documents synchronized with the program.

In the process of writing a document, the content of the document should be put in the first place. You cannot waste too much time on the format of the document.