The most important requirement for software development is to break down the use case scenario.

[Sina Vivi] [poco network Abstract] [365key] [bo cai] [Yi You Xiang] [you abstract] [younote] [Tianji network Abstract] [Hexun network Abstract]

Software Engineering is a kind of book to learn, but the most critical requirement of software engineering is the rational establishment of use case scenarios. This article seems to have no university textbooks to talk about, it seems that Chinese university teachers in the Computer Science Department have not done any software projects, and they do not have this concept at all. The so-called software requirement, if it is not a pseudo-code that cannot be passed through, or an artist's solution that cannot be used, is not easy for programmers ..

The biggest reason is that many people engaged in websites or similar software requirements do not understand what the real software requirements are, including the SAP/ERP projects I have handled, although it is not a website, the common mistake they make is to regard the form of webpage (which is actually a job of the artist) and content collection as a requirement, there is no concept of a use case.

Use Cases, usecase, are mostly seen in the expression of object behavior in object-oriented programs in UML. However, this is not its source; it is regarded as a standard URL description method for such languages because object-oriented itself works like simulating the real world in virtual programs, and the real world is centered on use cases. The concept of use cases cannot be regarded as a software concept, but it is the most accurate definition in the software field. Today, from the context of every person's life, death, and marriage, it is actually the description and implementation of use cases one by one. The use case refers to the action taken in case of a certain situation, and the possible result. Then, based on the result, what kind of action do you take ...... until you get a desired final conclusion.

A use case is also called a scenario. Software is actually a description of the scenario operation process, rather than the integration of a bunch of web pages. Without the support of use cases, software is not called, and project is not even called garbage. Many times we say that the requirements are not clear. In fact, this case is not clear. in e-commerce websites, apart from the quality of personnel, we cannot understand the basic concepts and methods, the most possible cause is that the business model is unclear or cannot be established. Whether this is true or not can be inferred from the preceding formula. Therefore, a programmer has two levels: one is what you say, and the other is what you do, but there is no result. He does implement all the requirements you (the requirement personnel) put forward, but this project will inevitably have no results, because it only uses this programmer as a Web Editor, the project does not support basic use cases. I think 90% of programmers are such "programmers". without the explicit definition of use cases, there is no software capability evaluation, because the software personnel are not artists. Another programmer can find out from the appeal deduction whether the entire project itself has use cases and whether the use cases are reasonable (there is no obvious logical obstacle in theory ); although programmers generally do not need to care about the rationality of business models, in fact, they are the first to discover the problems of business models.

It is a pity that most users do not understand this truth, but may think that programmers are shirking their responsibilities or making demands difficult, conflicts between the demand personnel and the implementer personnel are common in the project. It is not a conflict between the individual and the implementer personnel, but the failure of both parties to have a basic foothold. I have seen such a project. The requirement for a person to build a large website is a very detailed description of each webpage in a large region. Each word is connected to every connection ...... the project manager tells a joke about the order in which each web page appears: in case of a fall, the ghost will be able to look back. Indeed, the customer's deputy boss and a group of enterprise demand editors have worked hard for two months. However, this is not a requirement, but a specific editing and layout arrangement for the Project software; it is not something programmers should look. What programmers need is the use case logic that requires when using this website, and then abstract the objects in it, and establish storage methods (such as database storage structure) and content picking methods based on the objects. In fact, it is useless. When developing software, for example, building a house together, the onlookers may ask: "Building a house" is just a simple explanation, but for developers, if the Accurate Design of the House is not accurate to the accurate design of bricks and tiles (requirement definition), you must know that both the construction of a small bungalow and the construction of Jinmao grand summer are the construction of a house, and the construction of a hotel or funeral parlour is also the construction of a house, whether the customer wants a suitable house or fails to figure out the program is irresponsible or fake goods.

Personnel who do not understand the software requirements generally make the following mistakes: first, they regard the layout art form as a requirement. In fact, the programmer sees the program as a doctor looking at a person through X-ray and sees the skeleton, if the beauty is still ugly, the doctor must be abnormal. in the development process, he emphasizes the implementation of the use case function, rather than the first steps of how the colors are beautiful. The latter is not the main one, it is not secondary, and nothing is involved in the development process. It is a waste of time and money to focus on it as a demand implementation. The second is to regard static web pages as requirements, especially when static Web pages are regarded as prototype. This error is often said: "Just do it with prototype? "In fact, if prototype itself is not clear about the use case logic, there may be several Use Case interpretations. What's more, it actually turns into a dynamic program, which is different from static things. The beauty stars I saw on the Internet became ugly when they got down. What's even worse, the customer also made the first mistake at the same time, and the layout was changed three times a day when he looked at it, and the basic use case became another thing without knowing it, it turns out that a hotel is now a funeral parlour. I was wrong because I don't know whether people lie in different pavilions (dead or living). How can I achieve this? The same layout that you see at the beginning and later stages of the project is definitely a frequent story. demand changes in software are the main reason for frequent project delays.

Third, the requirement personnel should understand customization to cater to static pages according to all the customer's ideas, rather than establishing corresponding programs according to the customer's Business Use Case requirements. programmers should also do the same. In fact, if it cannot be done, any project is no longer a dead end: it is not software, it is nothing more than static Web page staff rental! Another common mistake made by the requirement personnel is that they do not understand the use case as a requirement. This mistake is sometimes made by junior programmers. The most typical mistake is to treat a menu column as a requirement, programmers cannot see the concise use case logic from the menu-this is a meaningless menu. What is Tian xiao'er? Similarly, the things to be done are changed three times a day. In fact, the same logical use case can use n columns, which are "use of software rather than the software itself ".

The above errors are common in website construction. Therefore, the most common outcome of website construction is that the website construction fails, which accounts for more than 50% of the total. This is true regardless of the amount of money invested, the amount of time spent, or the amount of time spent; unless someone is able to make things happen, let the project demands go straight. In ERP/DRP projects, the demand personnel are usually business experts, but they are easy to understand what the use case is, such as hospital fees, I will never focus on the charging interface whether there are any dancers to make the toll collectors pick up. They understand how many links are involved in the charging case. The most common mistake of such project requirements is to repeat the unreasonable processes in the original state with advanced computer tools. The most typical joke is that manual approval requires five chapters in five days. Now, the efficiency of computerization has increased by one hundred times, so you can add five hundred chapters (Electronic Signatures !), The time is still five days! Here, the contradiction is not whether there are use cases, but whether the use cases are reasonable and most efficient.

Therefore, if a programmer does not want to accept all the responsibilities due to case conflicts, it is best to stick to the principle. It is meaningless for a programmer to cater to webpage writing, it doesn't make sense to accommodate demands, because ...... the more you move, the less you can achieve it, or the customer cannot be satisfied. The software is actually very simple, it is nothing more than an example of analysis, and then let the computer implement it step by step. The use case is the prerequisite for all software implementation: otherwise, what the software will do?
? Good software projects share a common feature: simple logic and clear use cases. The most typical is Google and eBay.