Of course, the architecture of the initial software is very important. However, no matter at the beginning of software design, or in the process of using the software, during the maintenance process, the communication between the characters at the project manager level, etc., etc., etc., are inseparable from the document.
When it comes to documentation, we must mention three major documents: requirements, summary, and detail. As the saying goes: everything is difficult at the beginning, and this requirements analysis document is the head of the system, which mainly solves the problem of "what to do". During requirements analysis, system analysts and software engineers fully understand the needs of customers, and then organize the understanding of business requirements into documents. This document is used by the architect to construct the system, including the subsequent drawing of UML diagrams, the preparation of general design documents and detailed design documents.
Personally, I think that there can be a use case description in the requirements analysis document. Use case description is the best language between users and developers. In general, it is difficult for developers to hear what system users want, and users can't express what they want when they describe it in their own language for a long time. The use case diagram enables them both to reach a consensus.
In the needs analysis, user characteristics should also be placed. As the saying goes: Know yourself and the enemy, and you will be victorious in a hundred battles. Only by knowing the characteristics of users can we prescribe the right medicine and formulate a system that meets their needs.
Of course, some other things need to be put in the requirements, such as performance descriptions, non-functional requirements, etc., there is not much to say here, you can go to the encyclopedia to check. The following is an overview.
So, what is an outline design document, and who should I show it to after it's written?
Personally, I think that the writing of the outline design document is to specify the system according to the requirements of the requirements document. The functions of the system are divided into modules, the hierarchical structure calling relationship of the modules is established, the interface between the modules and the man-machine interface are determined, and so on.
So who will the outline design document be shown to when it is complete? After yesterday's stimulating discussion, everyone must know. First of all, the outline design should be read to the person at the project manager level. Through this document, he can understand the overall situation of the system and the features and highlights of the system. Then, the outline design can also be shown to users. After simple training, users should generally have no problem reading the document. They can know whether the system is the system they need through the document. Then, the outline design also Can be intimidating. For example, in outsourcing projects between companies, you can use the outline design document to brag about the two points and difficulties of your own project, giving people a shocking feeling.
We know who the outline design document is to be viewed, so what should our outline design include?
The outline design document needs to have the function introduction of the system, but not the concrete realization of the function. Of course, we can put a use case diagram inside. We can put the use case diagram we modeled inside the high-level design, so that people who refer to the document can see at a glance what the system does.
In addition, we can put the main function interface of the system in the document. The reader's ability to absorb multiple pictures is much greater than that of words. A few simple function pictures can summarize the main functions of your system.
In addition, we can also put the frame design of the database, the table design and the overall architecture of the system (that is, the package diagram) in the outline design. The purpose remains the same, to give users a global view of the system.
At the same time, we can also unify our programming specifications in the high-level design document.
Personally, I think that the outline design is like the face of a person, it is the face of the system. Through this face, we can see whether the system is beautiful or not, how much it is worth, whether it has any face, and whether it can bluff people.
With the outline design in hand, let's move on to the detailed design.
Detailed design documents must be meticulous. Because it is mainly for programming developers, everyone must write code strictly according to the detailed design document, so the accuracy of the document must be high. It can be said that there is a problem with the document, then the system must have problems.
In the detailed design document, the interface between the various levels should be included. For example, if I write the code of the UI layer, then I must know which classes, methods, and other parameters, return values, etc. BLL has. Then these must have detailed Chinese description and English name in the detailed design document.
This is the interface, so what else needs to be written in the detailed design? We can also put timing diagrams inside. I all know that the sequence diagram is the specific implementation of the specified function. The sequence diagram of the main function of the system is placed in the detailed design document, so that developers can call the relationship between layers, method names, parameters, and return values. and so on to know more.
In addition, the specific details of other aspects of the system should also be declared in the detailed design document. For example, the accuracy of the system, the necessary functions of the program, the description of the performance, etc.
The outline design document divides the system into modules, and the detailed design should gradually refine each module until the developer can easily understand it.
When it comes to documentation, we must mention three major documents: requirements, summary, and detail. As the saying goes: everything is difficult at the beginning, and this requirements analysis document is the head of the system, which mainly solves the problem of "what to do". During requirements analysis, system analysts and software engineers fully understand the needs of customers, and then organize the understanding of business requirements into documents. This document is used by the architect to construct the system, including the subsequent drawing of UML diagrams, the preparation of general design documents and detailed design documents.
Personally, I think that there can be a use case description in the requirements analysis document. Use case description is the best language between users and developers. In general, it is difficult for developers to hear what system users want, and users can't express what they want when they describe it in their own language for a long time. The use case diagram enables them both to reach a consensus.
In the needs analysis, user characteristics should also be placed. As the saying goes: Know yourself and the enemy, and you will be victorious in a hundred battles. Only by knowing the characteristics of users can we prescribe the right medicine and formulate a system that meets their needs.
Of course, some other things need to be put in the requirements, such as performance descriptions, non-functional requirements, etc., there is not much to say here, you can go to the encyclopedia to check. The following is an overview.
So, what is an outline design document, and who should I show it to after it's written?
Personally, I think that the writing of the outline design document is to specify the system according to the requirements of the requirements document. The functions of the system are divided into modules, the hierarchical structure calling relationship of the modules is established, the interface between the modules and the man-machine interface are determined, and so on.
So who will the outline design document be shown to when it is complete? After yesterday's stimulating discussion, everyone must know. First of all, the outline design should be read to the person at the project manager level. Through this document, he can understand the overall situation of the system and the features and highlights of the system. Then, the outline design can also be shown to users. After simple training, users should generally have no problem reading the document. They can know whether the system is the system they need through the document. Then, the outline design also Can be intimidating. For example, in outsourcing projects between companies, you can use the outline design document to brag about the two points and difficulties of your own project, giving people a shocking feeling.
We know who the outline design document is to be viewed, so what should our outline design include?
The outline design document needs to have the function introduction of the system, but not the concrete realization of the function. Of course, we can put a use case diagram inside. We can put the use case diagram we modeled inside the high-level design, so that people who refer to the document can see at a glance what the system does.
In addition, we can put the main function interface of the system in the document. The reader's ability to absorb multiple pictures is much greater than that of words. A few simple function pictures can summarize the main functions of your system.
In addition, we can also put the frame design of the database, the table design and the overall architecture of the system (that is, the package diagram) in the outline design. The purpose remains the same, to give users a global view of the system.
At the same time, we can also unify our programming specifications in the high-level design document.
Personally, I think that the outline design is like the face of a person, it is the face of the system. Through this face, we can see whether the system is beautiful or not, how much it is worth, whether it has any face, and whether it can bluff people.
With the outline design in hand, let's move on to the detailed design.
Detailed design documents must be meticulous. Because it is mainly for programming developers, everyone must write code strictly according to the detailed design document, so the accuracy of the document must be high. It can be said that there is a problem with the document, then the system must have problems.
In the detailed design document, the interface between the various levels should be included. For example, if I write the code of the UI layer, then I must know which classes, methods, and other parameters, return values, etc. BLL has. Then these must have detailed Chinese description and English name in the detailed design document.
This is the interface, so what else needs to be written in the detailed design? We can also put timing diagrams inside. I all know that the sequence diagram is the specific implementation of the specified function. The sequence diagram of the main function of the system is placed in the detailed design document, so that developers can call the relationship between layers, method names, parameters, and return values. and so on to know more.
In addition, the specific details of other aspects of the system should also be declared in the detailed design document. For example, the accuracy of the system, the necessary functions of the program, the description of the performance, etc.
The outline design document divides the system into modules, and the detailed design should gradually refine each module until the developer can easily understand it.