Requirements (4)

Requirements (4)
Http://www-900.ibm.com/?works/ I /c.gif business model creation period (below)
Lin Xing (iamlinx@21cn.com)
Different from the previous article in November 2001, This article focuses more on practice and lists some principles and practices that need to be paid attention to in brief business modeling. Each article comes from practice, both have theoretical support. Many of them are summarized after several failures. I believe that if you can understand these principles and some aspects of practice, you can at least avoid repeating the same mistakes.
Principle)
1. Who is "God"
<We say that the customer is God because the customer is important and plays a decisive role. But in software development, who has the right to decide? Is it the investor, project experience, or programmer?
Unclear responsibilities are one of the main causes of service modeling failure. We can easily see that customers use a few words to highly concentrate their requirements and then send them to developers, or developers can develop programs according to their own meanings. It is hard to say that there is no need to communicate between customers and developers.
I have mentioned the rights and obligations of project stakeholders and developers in the previous article. I think it is necessary to emphasize again here. Scott W. Ambler said:
It is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them.
During a development process, I encountered a very interesting stakeholder who wrote in his demand analysis: "In short, You need to implement the function that you can think. "I think this stakeholder has a great ambition for our computer industry. But I told him bluntly that the current implementation is not realistic.
It may sound funny to everyone, but there are not a few such customers in my career dealing with customers. The reality is that, what do you do? After a smile, do you abandon it? I think most people will do this. Because his request is so absurd. However, do you take the time to understand what he means behind his absurd words? In my opinion, software developers have the obligation to educate people. You need to guide your stakeholders and let them speak their own voices. After seeing this stakeholder sentence, I spent some time learning about it. In fact, it was very simple. He just wanted a function that could customize report templates. After the project was over, I had the honor to cooperate with this stakeholder again. At this time, he has become a project leader of outstanding clients.
What does this example show? The stakeholders are usually field experts who have a deep understanding of their own work. However, due to lack of understanding of software development, the stakeholders are often unclear and even unable to express their own needs. At this time, it is time to reflect your skill. Remember, treat your customers like God.