Overview of Software Development Documentation

The document has been poorly written. This is especially true for the last acceptance of the charging system. This is related to the lack of project development experience and the inertia that you are too lazy to summarize. Therefore, I want to combine my previous experience with it, A more systematic summary of the system development documentation.

Before describing each document, we need to take a look at other issues related to document writing, so that we can understand the document from both the aspect and the macro level. First, let's take a look at the software development and design personnel to solve the "who" Problem in the document.

Personnel Composition

Personnel	Function
User	Participants and end users of software development are responsible for providing requirements and correcting deviations in development.
Project leader	Coordinates the relationships among developers, users, developers and users, and leads the development of the entire project.
System Analyst	Responsible for communication between users and developers, which can be seen as the core character of system development. The main task is to convert the requirements expressed by customers into those used for development, revise the demand deviation in future development, and work with the user to develop test standards, test plans, and prepare data in the test phase.
Hardware network designer	Propose basic requirements for the hardware network and formulate the hardware network configuration scheme according to the development requirements. Implement the scheme.
Database Administrator	Designs, defines, and stores databases based on developed data requirements, and supervises, controls, and maintains databases during system operation.
System designer	Responsible for the overall design of the hardware and software environment, module design, and inter-Module Interface Design.
Programmer	Implement various functions in the solution; user use training; system test and test run

Classification is dead, and projects are active.The above is only composed of analysts. In real cases, roles are merged based on the system size and type. For example, for a small project, the team lead can also participate in code and testing.

You may feel the same way about the document.What is it, why it is written, who wrote it,What to write and who to writeThis series of blogs will summarize the writing of documents from these aspects.

What is it?

Documents are the main line of system development and construction. They run through the whole process of system development. Relevant documents are required at all levels and stages of development to record and confirm each stage of development. There are several principles for the document:

Standard Standardization	Develop standards for writing documents before system development, and write all documents under this standard
Consistency	Ensure consistency between documents and modify the associated documents of a document.
Traceability	Modifications made during system development must also be reflected in the document to ensure that the document corresponds to the developed version.
Systematic Management	Document management should also be systematic, including document standards, Document Modification Conditions, developers' responsibilities and tasks

The document is used to record the content, problems, solutions, and conclusions of the development process.Prerequisites.

Why?

I don't know why the document is coming. Why do I write it? Knowing why you want to write a document helps you understand the foothold and direction of the document.

Why write a document? Let's take a few examples:

1. Before development, the company will send you to see what functions the user needs. How can you tell the company when you come back?

2. You said that you know what features the user needs and how to demonstrate them?

3. What shall the user sign a contract with the company take as standard?

4. You call together several programmers and say: we need to develop a system, and then how to do it one by one?

5. After the software is initially completed, there may be various errors. The brain determines what to input for testing?

6. users do not know how to use the software. Do they teach them one by one?

I think these contradictions are the reason for writing documents: you sort out the functions required by the users and tell the team lead that this is what they want; sort out what the user requires and what the software should achieve, and hand it to the public, saying: this is an agreement between our company and the user. sort out what each programmer needs to do and tell him: just do this. You can sort out the information you know how to use and hand it over to the user. You can also copy it to the user to learn how to use it ......

There is no document or the document is not clear, just like developing a billing system in cooperation. I will ask what this function is? I will ask what parameters are required for this function, what types of parameters, and how to name them ...... In this case, the division of labor is almost zero, because the time is spent on communication.

What we need to sort out above can be referred to as the document in software development. With this document, what should we do? What is it? All have standards, and the division of work is more explicit. In short, it is: "The words are justified ."Power Supply.

Who wrote it?

The requirement specification, if any, is written by the user, is definitely different from that written by the developer. Therefore, you must know who wrote this document. If you know who writes the document, you can write the document from the perspective of this role.Start Point.

To whom?

Imagine the user-oriented documents. Users cannot see the full categories, architectures, data, and design patterns. Only when you know who you want to write the document can you know the language and method used to write the document. This is the document'sDirection.

What to write?

Each document has a specified expected reader. without mentioning the specific content, it is a great challenge to achieve the purpose of understanding, clear thinking, and simplicity of the document. In addition, the content of the document depends on the focus of the above writing, and then add details based on the specific development system. The focus of each document is also different, and the subsequent blogs will be detailed in detail.

The above are the key points to pave the way. This is the document'sSoul.

The software development document overview is provided here first. The following blog will detail the writing of common documents and precautions, so stay tuned.