Demand project? ? ? Deng Hui software is a commodity. Since it is a kind of product, it will inevitably meet the needs of the buyer. Yes, people will not pay for those who can't meet their needs. In addition, development software is costly. Only those costs that can meet the needs of customers can bring profits to software companies. Therefore, in order to make the software can bring the biggest benefits to software companies, a primary prerequisite is to figure out what customers need, that is, to figure out user needs. It is clear that the user needs can not only make the software developed independently of the user want to buy, but also avoid the cost due to the development of excess characteristics. Developing software that meets the needs is the most important condition for each software company to win in market competition. As a result, many software companies put the activities related to the software development activities in the most important position. These companies have conducted a lot of demand, analysis, and record training for project members. Attempting to standardize demand development, even specializing in the development team to provide a stable development of the project. Clear, clear demand set. It is very correct that it is very correct. Many companies have committed a lot of serious mistakes when they have implemented the concept of "value demand" in specific implementation. These errors are enough to make "value demand" into an empty talk. Below, we come to analyze these serious errors one by one. Error knows one: Trying pre-curing demand "software demand cannot be pre-cured, and may change at any time" is already a consensus of the entire software engineering industry. However, there are still many software companies attempt to curing demand before the project is actually developed. why? Because if you can curing the demand before the actual project development, it will greatly reduce the various risks and problems due to changes in demand. However, countless practices have shown that in terms of capturing demand, no matter how much you have a meticulous, no matter how much you do, no matter how much effort you have, demand will always change. The variability of demand is determined by the fierce market competition and the characteristics of the software itself. Customers companies will rarely maintain the original demand at that moment. If the customer wants to survive in the fierce market competition, it is necessary to adjust its business process according to the changes in the market, and this change reflects the required software accordingly. In addition, due to the invisibility of the software, sometimes the customer is not very clear about what you want, it is more important to say that demand is clear, clearly expressed. In most cases, only after seeing the real running system, the customer knows what you want. Therefore, when we find that the demand changes after the project enters the actual development, don't issue a "demand is not doing well". Because variability is the fundamental characteristics of demand. If you really pay attention to the demand, you should not try to cure it at the beginning. Paying attention to the demand is a continuous activity, trying to pre-curing the needs of demand is actually a lazy behavior. Error Cognition 2: The record of demand must be specified, detailed this statement itself has no errors, if the demand is recorded in the form of a normative, then others will be easier to understand, which is also conducive to communication. It is a key point here. When did you regulate the demand, that is, the timing of regulating the demand. Many demand analysis team always tries to record the needs in the way USE Case map at the beginning. The content of the discussion is often the form of more substance. They are disconnected in Preconditions, Postconditions, Actors, Secondary Actors, and many things that are not important at the current phase. In fact, for USE CASE, the most important thing is to keep simple. At the beginning, there is no need to pay attention to the form, and you will be recorded freely. There is no need to pay too much attention to details, and the details are only available in the later period.
Not try to record all USE Case, as mentioned earlier, this is an impossible task. Because the demand is likely to change, it is because it is to change, we don't need to record its details at all. The details of capture demand should be in a suitable time, generally "" In the first few days of starting to achieve this demand. "The most standardized, accurate demand is the acceptance test case that can be run automatically (these test cases can be very It is easy to understand whether the language is written, depending on whether it is truly attached importance to the demand), these test cases not only describe what features should be done very accurately, but also verify that these functions are properly implemented, and time and implementation. Synchronize. Those who have been very detailed in a very specified form, eventually produce some documents that are completely lost and actual needs. What is the value of such a document? Error knows the three: demand analysis and implementation is an independent activity "The analysis of the demand and the realization is not a coherent activity." This sentence seems to have no problem, the acquisition and analysis of demand is to figure out "what to do", After you know, you will do it (realize). Not? The problem is not as simple. To truly try your needs, it is important to communicate and communicate frequently, efficiently, and communicate, but the information obtained from communication and communication can only be used as a probably demand. If you want to truly figure out these needs, you must implement them. Only in the implementation, there are many things to clear. Only in realization can deepen the understanding of demand, and even inspire new needs, help customers get an advantage and get a win-win situation. Only in the implementation can discover better demand decomposition, so that the architecture of the entire system is evolved in a better direction. So, "Clear Demand" is a continuous activity, a test drive, feedback-driven iterative activity. Those who tried to limit the need to analyze the needs, fixed at a certain stage, at all, not to be called "value demand" practices. What is the demand project of the effective effect? Judging a certain activity is not an engineering practice, is not to describe and record the results of this activity in a certain specification or a popular way, not how many professional nouns appear in the description and record standard. Those who tried to curing the needs and using "specification, beautiful" USE Case diagram to record the needs of the engineering, those trying to analyze and implement fully isolated practices are not engineering practices. It is determined that an activity is not the primary standard for engineering. It should be: the process of this activity is not the basic law in the field it covers. Only in line with the basic laws of the field can really reduce the cost and risk of this activity is true engineering practice. For software, we must act in accordance with the features and regularities of the software itself when conducting demand activities. Compared with other fields, the most unique feature of software is: almost no cost construction and reversibility. It is these two characteristics that make us no need to invest a lot of energy and funds in the previous field, the product is correct, reliable (thinking of a large number of prototype experiments in aircraft engineering, wind tunnel test, etc.). Yes, we don't need to use the procedure to prove that the software is correct, and there is indeed no software company will do this, why? Because we basically make software manufactured in COMPILE, LINK, then verify the results, if there is a problem, change the software (reversibility). The verification here is necessary, to prove whether the program operates in accordance with the desired behavior, this is a process of exploring, deepens the process of understanding (in this process, it is likely to find an error in demand). The sole the earlier, the more frequently implements this process, the better the cost and risk of software development.
