Understanding of requirements and design

I. Understanding of requirements and design

For beginners, writing requirements and design will face many problems, and the difficulty is self-evident. The difficulty is that you do not know what needs to be written, the content included, the degree of writing, and what needs to be done. For the design stage, how should the design be connected with the needs, and how to design from the needs. HoweverItOn the other hand, the difficulty they need to write is how they call the difficulty of mining requirements and how to correct Potential false demands, what customers say is not necessarily what they want. The difficulty of development requirements lies in determining the scope of requirements and dividing requirements based on their priority levels. Therefore, the demand may only be covered in the early stage.20%-30%If the requirements are relatively stable and can meet the design requirements, you can enter the design. Of course, development is not stopped. The demand development will come to an end only when the project is completed.

Design, when you get the demand, you may be helpless again. The premise is that after you are familiar with the requirements, you will naturally come up with a brain to figure out how you can achieve it (it can be related to experience), from the data flow, come up with your own physical architecture (deployment diagram, such as what servers are needed and how servers interact), then the logical architecture, that is, your applicationProgramIt should be divided into several subsystems or services, and how they interact. These methods need to be further subdivided from macro to micro. Of course, you should always pay attention to your advantages and disadvantages, and whether it is conducive to software performance such as scalability. Finally, weigh the various solutions and select the solution that best suits the needs.

2. How to analyze requirements and design

Requirement Analysis Methods: structured requirement analysis methods and object-oriented analysis methods. Of course, the structured requirement analysis method depends on the flowchart and data flow diagram, while the object-oriented method mainly usesUsecaseTo describe and analyze the requirements. Of course, these two are just different forms of expression. In essence, they are all about how to resolve the requirements and explore the system requirements so that they can be summarized and designed.

Here we useUsecaseFor example,UsecaseIt is also a macro-to-micro analysis method.Usecase, EachUC (Hereinafter referred toUC)It is a home scene and an exception. The main scenario is a process of interacting with the system. Exceptions are handled when unexpected or unexpected situations occur during the interaction process. EachUCIt has the premise to enter, and the end status. PassUCThen you can know what functions the system must provide. Of courseUCDescribe the purpose and interests of executors and project-related personnel.

These are what needs to be done and should be recorded as the basis for subsequent work. For more information, see related books.

When demand analysis reaches the operational level (each person depends on his own experience, and the operational aspects are also different ). The use case can be implemented, and the use case can be implemented based on the collaboration diagram and activity diagram. Abstract As many objects as possible (mainly nouns). Of course, you can useCRCCard, write the responsibility of this object, completeCRCAt the same time, you will select these terms. Analyze the relationships between the remaining objects at the summary level (1:1,1:N,M:N, Combination, aggregation, inheritance, etc ). The summary-level static structure diagram can be called the domain model to be implemented by the system.

The outline design has completed more than half of the design journey. The outline design will directly affect the scalability and robustness of the system and other non-functional requirements. Therefore, we need to test the outline design at all times.VFor the model, from the perspective of requirements, you must always check whether your work is correct and effective. In this way, there will be very few rework and modifications in the future.

The next step is to implement specific functions. The detailed design mainly involves analyzing the functions of the system through the collaboration diagram, sequence diagram, and state diagram. By simulating the functions of the system through these graphs, we can know the summary classes and what fields and methods should be used for implementation. How to UseUMLFor more information, see related books. These are the details of the design, and written content. Of course, depending on different situations, check whether the method is false.CodeWrite. In this way, you only need to translate the code into a platform-related language.

3. How can we make a good request and design?

to make excellent demands and designs, you must pay a certain price. In terms of time and resources, it is up to the cost to determine the degree of demand. We do not assume these problems here. So what kind of requirements and design can be called excellent? Changes are inevitable when the demand remains the same. Only after the ever-changing and tested needs can we make a good design. Too stable demand may not be a good thing. Then, if we describe the demand, if it is a good demand, then these needs will be beneficial to the performer and the project-related personnel, then these needs will certainly be a good demand. No one will realize something that they don't want to see or want to use. But the demand is only better, not the best. Therefore, we should do our best to do this principle. It is only good to satisfy the customer's needs to the maximum extent. So what about a good design? A good design is the result of trade-offs. The premise here is not to consider costs, time, and other factors. A good design meets the functional requirements and non-functional requirements. The better the non-functional requirements, the better the design. For a system, the design is not the best, but better. It is better to obtain a balance between various factors (the balance is a major theory). The balance is not a one-person balance. It is achieved by integrating the views of individual and the purpose of the system. A good design is neither a design pattern that is full of sky, nor a small amount of code, with high execution efficiency. Sometimes, many things are one-sided. Consider it globally. Only by doing this can we call it a good design.