When developing a system, there is a process called design. This design process is the process of making a plan that will be important in future system development.
A design document is created at that time.
This is a document about “how to make a system”. In this article, I will explain such a DD.
table of contents
- 1. The design document includes a basic DD and a detailed design document.
- 2. About the items written in the DD.
- 3. Checkpoints in the DD.
■ There are basic design documents and detailed design documents in the design documents.
First, let’s see at what stage the design document is created in system development.
General system development proceeds in the process of “requirements definition-> design (external / internal)-> development-> test-> delivery”. In this process, a “basic design document” is required when performing external design work, and a “detailed design document” is required when performing internal design work.
Basic DD: A document that determines how the system behaves when viewed from the outside.
Detailed DD: A document that determines how to realize the movement determined in the basic design.
Many people think that a detailed DD contains more detailed information than the basic design, but it is best to divide it into “the part that can be seen by the user” and “the processing in the system”.
Reference article: ” What are” external design “and” internal design “? Explain the differences and work contents of each ”
● Design and specifications are different
Specifications are often confused with DDs. The specifications are “materials that explain what to build”. The purpose of the DD is very different because it is just a document that describes the construction method. In other words, you can see the results of system development but not the process just by looking at the specifications.
■ About the items written in the design document
In many cases, design documents are created together in Excel. Now let’s take a look at the contents of a general DD.
(* Contents vary depending on the project etc.)
■ System overview
■ System configuration diagram
■ Network configuration diagram
■ Business flow
■ Function list
■ Details of each function
■ Table definition
■ ER diagram
■ Screen layout (screen image)
■ Development system
■ Development schedule
The above are the items of the design document. The reason why the basic design document and the detailed design document are not classified is that the base of the detailed DD is the basic design document. In the detailed design flow, it is a task to think about the inside that is invisible to the orderer, so we will document the details such as the structure of the program and the flow of data. For example, the basic DD says “this function works like this”, and the detailed DD says “to realize that movement”.
■ Checkpoints in the design document
It is also good to know the checkpoints of the DD created in the system development work. Some may wonder, “Isn’t it okay to leave it to the engineers and programmers?” Should be taken.
Below are two items that you can check even if you are not familiar with the system.
● Point 1: Set priorities and check
One thing to keep in mind when checking is a priority. If you miss it, give priority to the ones that require a lot of man-hours to correct. It’s quite natural, but sometimes this is unexpectedly missed.
For example, you may be worried about typographical errors while checking the DD. Of course, if the typographical error has a significant negative impact on system development, it needs to be pointed out immediately, but in many cases, it is not. If you start checking mainly on those items, you may miss some really important check items. You may unknowingly turn your attention to typographical errors, but be patient and give priority to checking where it affects major program modifications and retesting.
● Point 2: Check if the numbers and data are concrete
Check that the numbers and data in the DD are specific. Ambiguous expressions can affect system bugs.
For example, if the expression “less than 100” is used, the interpretation will be different depending on whether it is 100 or less or less than 100. It’s a small point, but these items need to be thoroughly checked and clarified. The important thing is that the text can be interpreted in the same way by anyone.
So far, we have looked at the design documents for system development. It is not desirable to throw the design document to engineers and programmers. Even if you are not familiar with the system, be sure to check where you can check as an orderer. How about proceeding with system development by referring to the contents introduced here?
If you ever want to know about similar things, check out the Facebook page Maga Techs
