The importance of demand analysis and how to do a good job of Demand Analysis

Why is this the main question. this is because the demand for a shopping network is not well done recently. As a result, there is a one-to-one relationship between products and images at the front-end, and there are major drawbacks when adding products at the backend. and make up for vulnerabilities. no. there are too many logics involved. if you change this website, you can redo it. so it is a failure.

If a project fails due to a local error, all your recent efforts will be wiped out...
Therefore, if sufficient requirements are met before the project starts, and the requirements are put in place, the degree of demand thinking is strictly prohibited ..
(Reprinted below)
I. Why analysis of requirements

Requirement analysis is to analyze what software users need. if no one wants to invest a lot of manpower, material resources, financial resources, time, and software, 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 be re-developed, this rework is heartbreaking. (I believe everyone has some experiences.) For example, if a user needs a software for Linux, and you ignore the running environment of the software in the early stage of software development, he forgot to ask the user this question, it is assumed that the software for Windows is developed. When you submit the software to the user after a great deal of hard work, the problem occurs. At that time, you are crying, and you cannot find a piece of tofu.
(This problem is the most typical and most common. It is usually well avoided now. We all know some sensitive things about the project, for example, I want to see which areas of poor design may lead to bugs in future use .)

Ii. Requirement analysis tasks

In short, the task of requirement analysis is to solve the problem of "what to do", that is, to fully understand the requirements of users and to accurately express the accepted user requirements.

Iii. Requirement Analysis Process

The work in the demand analysis stage can be divided into four aspects: problem identification, analysis and synthesis, specification formulation, and review.

Problem identification
It is to understand the software from the system perspective, determine the comprehensive requirements for the developed system, and propose the implementation conditions for these requirements, as well as the standards to be met. these requirements include: functional requirements (what to do), performance requirements (what indicators to achieve), and environmental requirements (such as models and operating systems ), reliability Requirements (no fault probability), security and confidentiality requirements, user interface requirements, resource usage requirements (software operation is required for memory, CPU, etc ), software Cost consumption and development progress requirements, estimated possible system objectives in advance.

Analysis and Synthesis
Gradually refine all software functions, identify the relationship between various elements of the system, interface features and design constraints, analyze whether they meet the requirements, remove unreasonable parts, and add required parts. finally, the system solution is integrated to provide the detailed logical model of the system to be developed (what model to do ).

Develop specification
This document describes the requirement. It is called the Software Requirement Specification. please note that the results of the demand analysis stage are the requirement specification Statement (as if the soft exam has taken this test), which will be submitted in the next stage.

Review
Evaluate the functional correctness, completeness, clarity, and other requirements. The next stage of work can be carried out only after the review is passed. Otherwise, the demand analysis will be conducted again.

Iv. Requirement Analysis Methods

There are many methods for requirement analysis. only prototype methods are emphasized here. Other methods include structured methods and dynamic analysis methods (I personally think that I have never used these methods for beginners) not discussed here.

The prototype method is very important (it is a common knowledge point such as the soft test). prototype is an early runnable version of the software, which implements some or all of the functions of the target system.

The prototype method is to build a rough system as quickly as possible, which achieves some or all of the functions of the target system, but the system may be reliable, interface friendliness or other defects. the purpose of building such a system is to check the feasibility of a certain aspect, such as the feasibility of algorithms, technical feasibility, or whether the system meets the needs of users. for example, to check whether the prototype meets the requirements of users, you can use some software tools to quickly build a prototype system. The system is just an interface, and then listen to the user's opinions to improve the prototype. in the future, the target system will be developed based on the prototype system.

There are three main types of prototypes (soft tested): exploratory, experimental, and evolutionary. exploratory: the objective is to clarify the requirements for the target system, determine desired features, and explore the feasibility of various solutions. lab type: Before large-scale development and implementation, check whether the scheme is appropriate and whether the specifications are reliable. evolutionary type: the purpose is not to improve the specifications, but to make the system easy to change. During the prototype improvement process, the prototype is gradually evolved into the final system.

The prototype method has two different policies: discard policy and append policy. abandon strategy: first, build a model system with simple functions and low quality requirements, and modify the system repeatedly to form a good idea. Based on this, the system is designed to be complete, accurate, and consistent, reliable final system. after the system is constructed, the original model system is discarded. this policy applies to both exploratory and experimental models.

Append policy: first construct a model system with simple functions and low quality requirements as the core of the final system, and then gradually add new requirements to the final system by constantly expanding and modifying the system. Evolutionary Models belong to this strategy.

5. 20 Requirements Analysis Rules(This section is taken from the software engineering expert network)

The customer needs a good way to communicate with developers. The following 20 rules are recommended. Customers and developers can review the following content and reach consensus. In the event of any divergence, mutual understanding of their respective obligations will be achieved through negotiation in order to reduce future friction (for example, if one party requests and the other party does not want or cannot meet the requirements ).

1. Analysts should use expressions that conform to customers' language habits.
The requirement discussion focuses on business requirements and tasks, so you need to use the terminology. The customer shall teach analysts the terms (for example, procurement terms such as price collection and Printed Goods), and the customer does not have to understand the terms in the computer industry.

2. Analysts should understand the customer's business and objectives
Only by better understanding the customer's business can analysts make the product better meet their needs. This will help developers design excellent software that truly meets customer needs and meets expectations. To help developers and analysts, customers can consider inviting them to observe their workflows. If you want to switch to a new system, developers and analysts should use the existing system to understand how the current system works, the process, and the improvements they can make.

3. Analysts must prepare software requirement reports
Analysts should organize all information obtained from customers to distinguish business requirements and specifications, functional requirements, quality objectives, solutions and other information. Through these analyses, the customer can obtain a "Requirement Analysis Report", which allows developers and customers to reach an agreement on the content of the product to be developed. The report should be organized and written in a manner that the customer deems easy to read and understand. The customer reviews the report to ensure that the report content is accurate and complete. A high-quality Requirement Analysis Report helps developers develop products they really need.

4. Explanation of requirements
Analysts may use a variety of charts as a supplement to the text requirement analysis report, because the work chart can clearly describe some aspects of system behavior, therefore, various charts in the report have extremely high value. Although they are not easy to understand, customers may not be familiar with them, therefore, the customer can ask the analysts to explain the role of each chart, the significance of the symbol and the results of the requirement development work, and how to check whether the chart has errors and inconsistencies.

5. Developers should respect customers' opinions.
If users and developers cannot understand each other, there will be obstacles to the discussion of requirements. Joint Cooperation can enable everyone to "Listen to things ". Customers involved in the demand development process have the right to ask developers to respect them and cherish the time they have paid for the success of the project. Similarly, the customer should also respect the efforts made by developers for the joint goal of project success.

6. Developers should provide suggestions and solutions for requirements and product implementation.
What the customer calls "demand" is already a practical implementation solution. Analysts should try their best to understand the real business needs from these solutions, at the same time, it is necessary to find out the inconsistency between the existing system and the current business to ensure that the product will not be ineffective or inefficient. After thoroughly understanding the affairs in the business field, the analysts can propose a very good improvement method, experienced and creative analysts can also propose more valuable system features that users have not discovered.

7. describe product features　
Customers can ask analysts to pay attention to the ease of use of software while implementing functional requirements, because these easy-to-use features or quality attributes can help customers complete tasks more accurately and efficiently. For example, customers sometimes require "user-friendly", "robust", or "efficient" products, but developers are too subjective and have no practical value. The correct method is to ask and investigate the customer's "friendly, robust, and efficient" specific features, and analyze which features have a negative impact on which features, balance the performance cost with the expected benefits of the proposed solution to ensure reasonable trade-offs.

8. allow reuse of existing software components　
The requirement is usually flexible. Analysts may find that an existing software component is consistent with the requirement described by the customer. In this case, analysts should provide some options for modifying requirements so that developers can reduce the development cost and save time for the new system, without having to strictly describe the development according to the original requirements. Therefore, if you want to use some existing frequently-used commercial components in the product, and they are not fully suited to the features you need, the demand flexibility to a certain extent becomes extremely important.

9. A true and reliable assessment of the cost of the change is required.
Sometimes people may make different choices when they face better and more expensive solutions. At this time, it is necessary to evaluate the impact of demand changes to help with business decision-making. Therefore, the customer has the right to require developers to provide a true and credible assessment through analysis, including impact, cost, and gains and losses. Developers cannot arbitrarily exaggerate evaluation costs because they do not want to implement changes.

10. Obtain a system that meets the customer's functional and quality requirements
Everyone wants the project to succeed, but this not only requires the customer to clearly inform developers of all the information required for the system "what, in addition, developers are required to clearly understand the trade-offs and restrictions through communication. Your assumptions and potential expectations must be clearly stated. Otherwise, the products developed by developers may not satisfy you.

11. Explain your business to analysts
Analysts rely on customers to explain business concepts and terms, but they cannot expect them to become experts in this field, rather they can only understand your problems and objectives; do not expect analysts to grasp the subtle potential of the customer's business. They may not know the "common sense" that is appropriate for the customer ".

12. Take the time to clearly describe and improve the requirements 　　
The customer is very busy, but in any case, it is necessary for the customer to take time to participate in discussions, interviews, or other activities to obtain the demand. Some analysts may have explained your point of view first, but later I found that you still need to explain it. At this time, please be patient with the repetitive work of refining some requirements and requirements, because it is a natural phenomenon in people's communication, it is very important for the success of software products.

13. Describe requirements accurately and in detail
It is very difficult to compile a clear and accurate requirement document. Because it is not only annoying and time-consuming to deal with details, it is easy to leave ambiguous demands. However, this ambiguity and inaccuracy must be solved during the development process, and the customer is the best candidate to make a decision to solve these problems. Otherwise, developers have to make a correct guess.

Adding the "TBD" sign to the demand analysis is a method. This flag can be used to indicate which information needs to be further discussed, analyzed, or added. Sometimes it may be difficult to solve a special requirement or no one is willing to deal with it and marked with "TBD ". The customer should try to clarify the content of each requirement so that analysts can accurately write them into the "software requirement report. If the customer cannot accurately express it at the moment, it usually requires the use of prototype technology. Through prototype development, the customer can repeatedly modify it with the developer to continuously improve the requirement definition.

14. make a timely decision 　　
Analysts will ask the customer to make some choices and decisions, including the handling methods proposed by multiple users or the selection of compromise schemes in quality characteristics conflicts and Information accuracy. Customers with the right to make a decision must actively take this action and make a decision as soon as possible, because developers usually wait until the customer makes a decision, and such a wait will delay the progress of the project.

15. Respect the feasibility and cost assessment of developers' needs 　　
All software functions have their own costs. Some of the product features the customer hopes may not work technically, or they may have to pay a very high price to achieve it, while some of the requirements try to achieve performance that is not possible in the operating environment, or try to get some data that is not available at all. Developers will make negative comments on this and customers should respect their opinions.

16. Prioritize requirements 　　
Most projects do not have enough time or resources to implement every detail of functionality. Determining what features are necessary and what are important is the main part of demand development. This is only the responsibility of the customer to set the demand priority, because developers cannot determine the demand priority based on the customer's point of view; developers will give you priority information on the costs and risks of each requirement. The opinions of developers on whether or how many features are required should be respected under time and resource restrictions. Although no one is willing to see that their desired needs are not implemented in the project, after all, it is necessary to face the reality that business decisions sometimes have to narrow down the project scope or extend the construction period based on priorities, or increase resources, or find a compromise on quality.

17. Review Requirement documents and prototypes　
The customer review requirement document is an opportunity for analysts to provide feedback. If the customer deems that the "Requirement Analysis Report" is not accurate enough, it is necessary to inform the analysts as early as possible and provide suggestions for improvement. A better solution is to first develop a prototype for the product. In this way, the customer can provide more valuable feedback to developers so that they can better understand your needs. The prototype is not a practical application product, however, developers can convert and expand the system into a complete system.

18. contact us immediately for request changes.
Constant demand changes will have a serious adverse impact on the quality products completed in the planned plan. Changes are inevitable. However, during the development cycle, the more advanced the changes appear, the greater the impact will be. changes will not only lead to costly rework, but also delay the construction period, especially when new features need to be added after the general structure is completed. Therefore, once the customer finds that the requirement needs to be changed, inform the analysts immediately.

19. Follow the development team's process of handling demand changes　
To minimize the negative impact of changes, all participants must follow the project change control process. This requirement does not discard all proposed changes, analyze and comprehensively consider the changes in each requirement, and finally make appropriate decisions to determine which changes should be introduced into the project.

20. Respect the demand analysis process adopted by developers
The most challenging thing in software development is to collect requirements and determine their correctness. The methods adopted by analysts are justified. The customer may think that the collection process is not cost-effective, but please believe that the time spent on demand development is very valuable; if you understand and support the technologies used by analysts to collect, compile Requirement documents and ensure their quality, the entire process will be smoother.

What does "requirement confirmation" mean?

Signing and confirming on the "Requirement Analysis Report" is usually considered a sign of customer's consent to the demand analysis. However, in actual operations, the customer often regards the "signature" as meaningless. "They asked me to sign the signature under the last line of the requirement document, so I signed the signature. Otherwise, these developers will not start coding ."

This attitude will cause trouble. For example, if a customer wants to change the demand or is not satisfied with the product, he will say, "Yes, I signed the demand analysis report, but I don't have time to read all the content. I believe that you did not ask me to sign it."

The same problem also occurs when only the "signature confirmation" is seen as the analysis personnel who complete the task. Once there is a demand change, he points to the "Requirement Analysis Report" and says: "You have signed your request, so these are what we developed. If you want anything else, please let us know earlier."

Both attitudes are incorrect. Because it is impossible to understand all the requirements in the early stages of the project, and there is no doubt that the requirements will change. Signing the "Demand Analysis Report" is the correct method to terminate the demand analysis process, therefore, we must understand what signatures mean.
　　
The Requirement Analysis Report signature is built on the basis of a requirement protocol. Therefore, we should understand the signature as follows: "I agree that this requirement document expresses our understanding of the Project software requirements. Further changes can be made through the project-defined change process on this basis. I know that changes may allow us to negotiate costs, resources, and project tasks again ." Reaching a consensus on demand analysis will make the two sides easy to endure future frictions, which come from project Improvement and demand errors or new requirements of the market and business. The confirmation of the demand separates the fog and shows the true face of the demand, draws a clear conclusion on both sides of the initial demand development work, and helps to form a continuous and good relationship between customers and developers, it laid a solid foundation for the success of the project.

6. misunderstandings in 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) originality and truth-seeking
No doubt, everyone will be excited about a new idea, especially when it 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) anatomical pleasure
Almost all people engaged in software, when doing demand analysis, will first tell you the requirements of the user, complete the whole anatomy, cut into several pieces, 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
I 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 hundreds or even thousands of times every day, A change reduces the workload by half. 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.

(4) programmer Logic
Growing from a programmer to a system analyst is a general track, but not a good programmer will inevitably 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.