Analysis of the demand for exhausting brains

Summary: Why have they changed? The customer should have a written signature at the beginningConfirm! You may often complain like this, but even if the customer confirms in writing, the customer will still "Review" it!SoftwareOne of the unchanging truths of the project is that people will die and needs will change! This chapter will work with you to experience the softwareRequirement AnalysisWork ups and downs, find out the fundamental way of demand analysis, understandUMLHow to help us improve the level of demand analysis.

Author:

Zhang chuanbo
Www.umlonline.org
Www.umlonline.org/school/

This article is from the second chapter of the new book "use UML-demand analysis experts.
Chapter 1 has been published in the blog Park,ArticleThe name is UML.
Article: http://www.cnblogs.com/umlonline/archive/2011/07/12/2104626.html

The following is the text:

2.1 requirement analysis Overview

What the customer needs is a ladder. What the system analyst understands is a stool. What the developer makes is a table. The tester thinks it is a chair ...... Many roles are involved in the project. Each role understands the requirements from its own roles, so that different roles have different understandings of the requirements. The following table analyzes the features of various roles:

Table 2.1 features of various roles

It should also be noted that:
The customer's general tendency is to make software companies do more with less money.
The general tendency of a software company is to take the customer's money and do as little as possible.
There are two main factors that affect everyone's understanding of needs: one is the thinking tendency of the role, and the above table reflects this; the other is the ability to analyze human needs, more competent people can grasp their needs. This book focuses on howUse UMLTo improve the demand analysis capability.
What is even more "outrageous" is that the demand in each person's mouth is always different from that in the mind. The so-called "bad words" is limited by the ability to express, not everyone can express their ideas completely and accurately. Sometimes customers want this today, tomorrow, or even don't know what they really want! In fact, the customer's performance shows that the customer's understanding of the demand is constantly evolving.

2.2 evolving customer needs

You may have encountered a situation where a customer wants an Apple today and wants a banana tomorrow. But the day after tomorrow, the customer suddenly says that it is still good. At last, he wants a watermelon! Will you complain about the customer in this situation? You will regret your failure to sign the customer.Confirm?

When someone was crossing the river by boat in the Chu state, he accidentally dropped the sword into the river. He carved a mark on the boat and said, "This is the place where I dropped the sword ." When the boat was suspended, he jumped into the river along the mark to find the sword. This is the story of searching for swords.
The customer's ideas are always changing, but in general the customer's thinking is a spiral forward, and the customer's needs are constantly evolving. Do not complain about this. Otherwise, we will be the one who cares for the sword!

A system has been launched. Which of the following three situations do you prefer?
A. The customer has never raised any questions.
B. The customer began to raise some questions, but soon there were no other questions.
C. The customer has been asking questions. After the project team solves these problems, new problems have emerged and are repeated.

Situation A: it is estimated that the customer has never used this system, so no questions have been raised. For the project team, it seems that there is no need to be entangled in troublesome demand changes, so you can leave the project easily. But for customers, the system has spent their money without any practical value to them. For yourSoftwareFor the company, the customer is unable to use the software system that your project team has spent a lot of work on, and your company may not receive the project acceptance fee, this project cannot fully implement the company's strategy. The final result of case A is "double-win ".

Case B has two possibilities: first, the customer tried the system for a period of time, and later, due to some reasons of the customer (the reasons may be: the customer no longer uses the system. The second possibility is that the customer tried the system for a period of time and raised many questions, however, your project team cannot solve these problems well, and even considers the customer to be "unreasonable", so the customer will simply stop using the system. In the case of B, it is estimated that the project will be difficult to pass the final acceptance. The software company will not be able to receive the Project Acceptance amount, and the final result is likely to be a "double loss ".

Situation C: I used to get bored with this situation. Every day, I am entangled in various small problems of the customer. In fact, this is an ideal situation, indicating that the customer is constantly using the software. At the beginning, there will be many problems. At the beginning, the project team will solve the problem at a lower speed than the problem generation speed, but the problem will gradually decrease until the problem disappears, the "Running-in" process between software and users has finally been completed, and the system has become part of the customer's daily work. In the case of C, the project team should never get bored. If the customer wants to use the software, the project will be truly successful. Only when the software is really helpful to the customer's work can the customer win. On the basis of the customer's ability to win, our software company can win ". Achieving "win-win" is our goal for every project.

From a certain point of view, demand change is actually a good thing, indicating that the customer's understanding of the demand is further improved. However, we feel that we are not adaptive because our understanding of the demand is not as advanced as the customer's. See:

Figure 2.1 customer vs project team's understanding of requirements 1

This figure shows that the customer and project team's understanding of the demand increases over time after the project starts.
When the time is 0, the customer's curve does not start from scratch, but has a certain starting point. This indicates that the customer has a certain understanding of the requirements at the beginning of the project. At the beginning of the project, the project team had almost no understanding of the requirements.
With the development of time, the customer's understanding of the demand is getting stronger and stronger. Although the project team's understanding of the demand is also strong, the project team's understanding of the demand is always lagging behind the customer.Requirement AnalysisWork must be passive, and customers will always be "holding their noses". It is easy to blame each other: Customers blame the project team for a poor level, while the project team blame customers for changing their needs!
To break this situation, the project team needs to achieve the following results:

Figure 2.2 Customer vs project team's understanding of requirements 2

At the beginning of the project, the customer had a better understanding of the demand than the project team, but the project team had a better understanding of the demand than the customer in a short time. After the "intersection", the project team's understanding of the needs is always ahead of the customer. The project team should have strong business learning capabilities, understand the real needs of customers, and plan software systems that truly meet their needs.

2.3 brings value to customers and the right path for Demand Analysis

SMS ordering system

Next, I will introduce the story of a text message ordering system. This is a story adapted from a real case.Requirement AnalysisThe principle behind work.
A small IT company has 100 employees. The company has a simple ordering system. Employees can submit their lunch ordering orders on the company's internal website every day. After the reception desk summarizes each person's ordering, the ordering summary will be sent to the restaurant. The restaurant will deliver meals by fax.

However, some employees cannot submit food orders on the website because they leave for work in the morning, so that they do not have any meals when they return to the company at noon.

So the boss came up with a method like this: to make a text message ordering system, employees who are not in the company can order meals via text message.
As a result, a text message ordering project team was set up to purchase the hardware for sending and receiving text messages, solving technical problems such as meal selection, ordering, and cancellation. However, this system will not work, but the problem isSoftwareHardware, or China Mobile, are hard to figure out! One of the things that make projects troublesome is to encounter "ghost Problems", which sometimes Appears normally, and the project team is sweating to solve these problems, but there is no way to solve them all the time.
My boss is furious. How can this happen to me?
Someone later proposed that an employee who is not in the company should call the company to tell the front-end what to eat?
So the world suddenly realized, oh, my God!

The core issue of requirement analysis is what the customer wants!
Customers often only have vague general ideas. What they propose is superficial, incomplete, or even conflicting. We need to understand its nature.
We often analyze the requirements andSoftware Design. The core purpose of requirement analysis is to solve the problem of software usage, and software design is to solve the problem of the cost of software usage.

The first task of requirement analysis is to ensure the value of the software. We must ensure that the software is in the interests of the customer. If we cannot clearly understand the real needs of our customers and rush to the market, it is very likely that the costs will not meet the customer's interests.

The problem solved by the text message ordering system is that it makes it easy for employees not working in the company to order meals. The text message ordering system is not a requirement but a solution. Of course, because this requirement was put forward by the boss, the project team may not have to think further about the necessity of this system. When our customers make specific requirements, we often cannot think about the requirements behind these requirements, but directly treat these customer requirements as customer requirements.
It is our real task to bring tangible value to our customers, rather than blindly following the customer's requirements without analysis.

Principle of Demand Analysis

Software requirementsWhat is the analysis work? How can we grasp the real needs of customers and make software systems that bring real value to customers?
Let's talk about the major principles of demand analysis:
First, we need to clarify the background of the project. We need to answer these questions: that is, why is this project? Why do customers want to do such a project? What will happen without this project?
Based on the background, we need to learn more about the following:
1) What problems does this project solve for customers?
2) who and what organization is involved in this project?
3) What are the objectives of this project?
4) What is the scope of this project?
5) What are the criteria for success of this project?
The above content is called the customer's "needs ".

Next, we can set detailed requirement specification. Generally, we will list detailed requirements for both functional and non-functional requirements. We define these requirements as "requirement specification ".

Figure 2.3 Requirement Specification for background

When analyzing requirements, we often only see the "requirement specification" layer, which is a superficial requirement. We should look at these surface requirements to find out the customer's "needs ". If we do not know the customer's "Needs", it is easy to be "confused" by "requirement specifications", and it is difficult to make software systems that are of practical value to the customer.

Let's review the features of various roles mentioned in the "Demand Analysis overview" section. The more grass-roots customers, the more likely they will put forward the "requirement specification" level requirements, the more senior customers, the more likely they are to put forward "Needs" level requirements. Of course, even the middle-level customers cannot clearly describe their "needs.
The project team should not only position itself in the software manufacturer, but should be the creator of the software value. We do not provide customers with a set of software systems, but a set of services that can enhance the value of customers. Therefore, the project team should not passively accept the requirements, but should take the initiative to help the customer identify the real needs and sort out the specifications that meet the customer's needs.
If we can say what the customer really wants, and what the customer cannot express, we can truly "bring value to the customer "!UMLThis will help us improve our demand analysis capabilities.

2.4 UML assists with Demand Analysis

In order to fully understand the customer's business, we can help us grasp the customer's needs accurately. While understanding the customer's business, we often need to re-engineer the business process. In short, BPR is the work of process improvement. In fact, the vast majoritySoftwareThe system must face the problem of process improvement. The previous software system was not as simple as converting manual work into information technology. It involved changes in work models, work habits, and management ideas, involving changes in the interests and interests of many people.
We can use structuredUMLStructure Modeling of customer services, and behavior modeling using UML diagrams. Systematic sorting and refining of static structures such as business concepts, called structural modeling; systematic sorting and refining of dynamic content such as business processes, called behavior modeling. These modeling activities will help us better understand the customer's business and do a good job of business process reengineering.

Figure 2.4 UML assistanceRequirement Analysis

This figure shows the general process of requirement analysis and the role of UML in this process.
Having mastered the powerful tool of UML will help our demand understanding curve to rise faster, achieve the effect of figure 2.2, better understanding of the demand than the customer, and bring greater value to the customer.
This section briefly introduces how to use UML to analyze requirements.Use UMLBecomeDemand Analysis experts.

2.5 Summary and exercises

Summary

The main purpose of this chapter is to "brainwash" you "!Requirement AnalysisThe work is actually very complicated and can be enough to write a book. However, I hope that I can only use one chapter to explain the basic principles of the demand analysis work, so that you can understand the root of the demand analysis work and understand that there is no shortcut to do a good job in demand analysis, only by improving your own level. Next we will review the main content of this chapter:
Understand the customer andSoftwareThe characteristics of various roles of the company can help us to analyze our needs more specifically. In general, the customer tends to spend a small amount of money to handle major events, while the software company tends to take more money and take less actions.
"Win-win" is the goal we should pursue. Only when the software is truly helpful to the customer's work can the customer be regarded as "win", and on the basis that the customer can "win, our software companies can achieve their own "win ".
Do not complain that the customer changes. The customer's understanding of the demand is always on the rise, and the same is true for the project team. If the project team lags behind the customer in terms of requirements, it will be "passive". The project team should strive to improve its level and find a way to lead the customer in terms of requirements.
Requirement Analysis is a complex and difficult task. If you cannot see the customer's real "Needs" clearly, you are likely to make the "text message ordering system" mistake again. The project team should not only position itself in the software manufacturer, but should be the creator of the software value. We do not provide customers with a set of software systems, but a set of services that can enhance the value of customers. The project team should not passively accept the requirements, but should take the initiative to help the customer identify the real needs and sort out the specifications that meet the customer's needs.
We should use itUMLStructural Modeling and behavior modeling help us better understand the customer's business and do a good job of business process reengineering.

Exercise

1. If you have experience in demand analysis, Please summarize the three most troublesome problems based on your actual experience. If you do not have specific requirement analysis experience, please list at least three points, which may be the most troublesome issue. Record these issues and see if the subsequent chapters can solve them.
2. analyze and describe what the situation is like? Should we pursue such a realm?

Figure 2.5 customer vs project team's understanding of requirements 3

--------------------------
The full text ends here!

This article has been made into a PDF file for download, download link: http://www.umlonline.org/school/thread-706-1-1.html

This article is from Chapter 2nd of the new book "use UML-demand analysis experts". click the following link to learn more about this book:
Http://www.umlonline.org/school/forum-140-1.html

Chapter 1 has been published in the blog Park. The name of this article is UML.
Article: http://www.cnblogs.com/umlonline/archive/2011/07/12/2104626.html

If you think this article is helpful to you, please click "recommendation". Thank you!