OOA & D practical path -- Analysis of real cases oo Theories and Practices (II. First task: feature list)

Description 1
At the beginning of this project, the only description we get about the system we want to do is a one-page Word document, which is a simple description. There is only one line in the document: we need a system that enables agents and chain stores across the country to order raw materials through the Internet. In addition, we also know that this is a food company that specializes in foods such as bread, twist, and meat sandwich. There are many chain stores throughout the country. We do not know anything about this.

Never talk to customers about requirements
What is the first step in software development? Many people think it is demand analysis. Obviously, this short sentence cannot meet our requirements. Naturally, you want to talk to the customer, learn more about the situation, and then make a detailed requirement analysis. Therefore, you have such an Abacus:

Talk to the customer-> ask all requirements-> perform Requirement Analysis-> Generate Requirement documents

At first glance, this is a reasonable step, but it is actually not feasible. The reasons are as follows.
1. the customer does not care about all aspects of the system
Every developer hopes that the customer can clearly tell you everything they need. However, this is just a wishful thinking. Because, when a customer needs something, he will only think about it, and will not think about it all over the world.
2. Sometimes the customer does not know what he wants.
Sometimes, customers are not very clear about what they want. This is not a fantasy. Most of the time, customers only have a "motivation to achieve a specific purpose", and there is no such clear concept as "What system do I need. For example, from the above "one sentence", we can see that our customers only have a motivation: they hope to have a system that can allow their agents and franchisees to determine online materials, as for what kind of system it is, they do not have a clear concept, let alone what specific requirements the system has.

Based on the above two points, you cannot ask all the requirements from the customer. In fact, we should not talk to the customer about the demand, because the demand is never a "customer" thing, but a "Developer" thing. Requirements need to include the functions that all systems need to implement, and customers often do not think so precisely, or even do not know what they want. In the face of such customers, you sit in front of him and develop a notebook and say, "Let's talk about the demand." Or, "Let's analyze the demand." I think the customer will crash immediately, and you cannot get everything you want.
As a developer, you should not first talk to the customer about requirements, but features.Many customers do not need to tell you that developers should be able to identify their requirements through common sense. Just as no one who buys a car would say: I need a car and have a steering wheel, there are four more wheels. They usually say, "I want a home car, fuel-efficient, comfortable, and at least three people ." This "Family Car" and "at least three people can sit" are features.
Features are some descriptions. A feature briefly describes a core function that the system is most concerned.
The primary task for developers is not to perform requirement analysis, but to help users sort out a feature list. The reason for saying "help" here is that many times customers miss a very important feature because they are too concerned about a certain aspect. You need to help them think about it, ask the customer for the desired features. If the customer is happy to say "Yes! Yes !", This is a major achievement. Therefore, in the initial stage, developers must think about what the customer thinks, and help the customer identify the characteristics of the system as soon as possible.
Therefore, the correct process should be:

Ask the customer what functions the system has-> write out the initial feature list-> think about any missing features, and ask the customer-> check for missing features

Generate a feature list
Return to the case below.
Although there is only one sentence for the customer's explanation, we will sort out an initial feature list and use it as the first work result we will present to the customer. The list of features is as follows:

1. Various raw material information can be published to the system.
2. franchisees and chain stores can determine materials online through the system

Yes, our initial documents only have two features. We showed this to the customer, and the customer said, "Well ...... It's about this thing ." Obviously, our customers are relatively lazy. At this time, we are obligated to remind our customers of more features they need. The following figure shows the conversation at that time:

Developer (D), customer (c)
D: How do you differentiate your franchisee from a chain store?
C: Our company has a record of franchisees and chain stores.
D: Are you going to input all the information of each franchisee into the system?
C: No. I hope they can register with the Forum.
D: Then, how do you determine their identity? No one can register in this system.
C: Well, our company has detailed information from various franchisees. We hope they will provide sufficient information for us to check.
(So we quickly wrote the next feature: the franchisees and chain stores register through the network, and the head of the store can only officially use the system after review .)
D: You have to publish information about various raw materials in the background.
C: Well, it makes.
D: Are there any special requirements.
C: No ......
D: Okay. How many people are you going to set up to manage the system.
C: Just one person, just the Information Department. We have a better understanding of computers.
D: that is to say, there is no need for multiple people to manage the system separately?
C: No.
(Write down the next feature: the system requires an administrator who can manage the system)
D: What do you want them to do when your franchisee determines the materials.
C: Well, I have never thought about it ......
(The customer is not clear about this place. We opened an online bookstore website and showed him the shopping process of the shopping cart)
D: You see, is your configuration process similar to this shopping process? Is it equivalent for a franchisee to buy raw materials from the company.
C: Yes! This is the result!
(Remember that finding similar things is a good choice when features cannot be clearly stated. That is to say, describe what this feature looks like)
(We add another feature: using the shopping cart function to set online materials)
D: How can I make the payment? Do I need to pay online?
C: No. We usually specialize in finance for money.
D: What creden do I need after I buy the raw materials?
C: generate a bill after purchase, print it out, and hand it over to finance and financial liquidation. After the payment is received, notify the raw material team to deliver the goods.
(Another feature: After the material is set, a bill is generated and can be printed)
D: You must be able to query these transactions.
C: Well, we have dedicated financial software on the finance side. You only need to allow the franchisee to set materials for this system.

At this point, the conversation is basically over. We will get a list of features that have been supplemented as follows:

1. Various raw material information can be published to the system.
2. franchisees and chain stores can determine materials online through the system
3. franchisees and chain stores register through the Internet. The system can be officially used only after the head of the general store reviews the system.
4. The system requires an administrator who can manage the system.
5. Use the shopping cart function to set online materials
6. After the completion of the set material, generate a set material order and print it

We showed the added feature list to the customer, which was basically recognized.
At this point, we have finished the first step. However, we still cannot enter the demand analysis immediately, because there are still many things to do before. For example, feature sorting and risk avoidance are all topics to be discussed later.

Summary
1. Customers will not think of all aspects.
2. Sometimes customers do not know what they want, but simply have a motivation.
3. Do not talk to customers about requirements or features.
4. Developers are obligated to guide and help customers explore system features.
5. When the customer cannot describe a feature, they can use the method of looking for similar things to talk about what the feature is like.
6. In the early stage of software development, we need to first sort out a list of features instead of requirement analysis.

Http://www.cnblogs.com/leoo2sk/archive/2008/12/08/1350674.html.