DRP Project (I)-importance of requirements

 

We will start to learn new projects. First, we will introduce the DRP (Distribution Resource Planning Distribution Resource Plan) We will learn next ).

DRP: an extension of the distribution demand plan, involving key resources in the distribution system, such as warehouse space, labor, monetary capital, and transportation tools, we will record the analysis and implementation of these problems from the perspective of software design.

A software starts from the needs of the software, and DRP is no exception. The DRP business needs are detailed in the video from instructor Wang. I will not write them in detail here. But not writing it does not mean it is not important.

In general, the software demand analyst can tell customers and developers what functions they need, how they are implemented, and on what platforms they need, after development, you should deliver those things.

Demand analysis is to analyze what software users need. If a large amount of manpower, material resources, financial resources, time, and software development are not required, all the investment will be futile, if you spend a lot of energy developing a software, but do not meet the user's requirements, and thus need to re-develop, this rework is a pain point.

Demand analysis is important because of its decision-making, directionality, and strategic role. It plays an important role in the process of software development. Everyone must pay enough attention to demand analysis, in the development of a large system project, it is much more effective than program design.

I. Requirement Analysis

1. understand customer requirements

2. Analyze System data requirements

Ii. Demand Analysis Process

1. problem identification: from the system perspective, we can understand the software, determine the comprehensive requirements for the developed system, and propose the implementation conditions and standards to be met. The requirements include: functional requirements (what to do), performance requirements (what to achieve), environmental requirements (such as models, operating systems, etc.), reliability (the probability of no failure), security and confidentiality requirements, user Interface requirements, resource usage requirements (memory, CPU, etc. required during software running), software cost consumption and development progress requirements, and estimated possible system goals in advance

2. analysis and Synthesis: Gradually refine all functions, identify the relationship between various elements of the system, interface features and design constraints, analyze whether they meet the requirements, propose unreasonable requests, and add demand, integrate the system solution to provide the detailed logical model of the developed system (what model is used ).

3. specification: Software Requirement Specification

Review

Evaluate the functional correctness, integrity, clarity, and other requirements, and confirm the function through another conversation with the customer.

Iii. Misunderstanding of Demand Analysis

If you want to talk about what is a good demand analysis, you should say what is a bad demand analysis. If you know what is bad, you will naturally know what is good. The following are some bad cases:

(1) There is no doubt about creativity and truth-seeking. Everyone will be excited about a new idea, especially when this idea is praised by people who do not know what you are going to do. However, when you are excited, you may have forgotten that you are describing a demand, rather than planning a idea and creating a concept. Many people who have just begun requirement analysis may make such mistakes more or less. They are intoxicated with their new ideas and new ideas, but violate the original objectivity and authenticity principles of requirements. Never forget: demand is not a castle in the air, but a brick and a tile.

(2) The pleasure of anatomy is almost all people engaged in software. When they do requirement analysis, they will immediately tell you the requirements, complete the anatomy, and cut them into several parts, then, it is subdivided into several sub-blocks and then analyzed. However, when users are confused and look at the analysis results you have worked so hard to make, they ask you: what do I want to do for a data backup task? At this time, you will find that you need to open three windows to complete this task. Never forget: decomposition is necessary, but the ultimate goal is to better combine, not to break down. (3) angle and thinking often hear such complaints: "How can users make such demanding requirements ?". By taking a closer look, you will find that users only need to change a function that requires two clicks to only one click. This will lead to the need to change the demand, change the code, or even re-test, increase the workload. However, if you think about it from another perspective, this function is only used several times or dozens of times during development, but users need to use it hundreds of times a day.
By tens of thousands of times, the workload has been reduced by half after a change. Is such a demand harsh for him? Never forget: It's not right if you don't have any requirements. what's wrong is your demand analysis. From the perspective of the user's thinking, your demand analysis will be closer to the user and more reasonable. Software should be people-oriented.

(3Programmer logic is a general track from a programmer to a system analyst, but not a good programmer is bound to become a good system analyst. Some programmers have solidified the logic, so that they often get into some horns when doing demand analysis. For example, the 1/0 logic (or the black and white logic) is not the case. There is no third case. But the actual situation is often that, at a certain time, this is the case, and at other times. Another example is the exhaustive logic. If you like to come up, you can list all the situations that may take up 1/3 of the time and process them one by one. However, the actual situation is often, 1/3 of the cases account for 99% of the total. The other two cases won't happen once a year. In fact, there are many such examples, which are not listed one by one.
Never forget: Demand Analysis and program design are different. reasonable and feasible are important. Jump out of the programming circle and look at the problem from a system perspective. Your conclusions will be totally different.