Old code Agriculture: Some experiences on the demand analysis

Intermediary transaction SEO diagnosis Taobao guest Cloud host technology Hall

In a blog post I wrote earlier, "How to write your own code of satisfaction," some readers mentioned in the comments that the uncertainty of user requirements is always a problem in the overall design phase. Requirements analysis is of course very important, even in some cases more important than the overall design. So how do you understand requirements analysis?

Google keyword "Demand analysis", the internet has a lot of relevant articles, and many have been written as a textbook as comprehensive and accurate, but also provides some of the best practices of the classification method. This article from personal experience to talk about their own experience.

First, the most important question is, why do needs analysis, or what is the meaning of demand analysis? Everyone may have a different understanding of the problem. In my opinion, the significance of the requirement analysis is to express the products that the project needs to deliver accurately and without ambiguity, and to obtain the approval of the demand side, thus establishing a benchmark for the whole project. It is almost impossible to expect that demand will not change, both the developer and the demand side are likely to propose changes as the project progresses, so the goal of requirements analysis (and change management) is not to define a requirement that will not be changed, but from the start of development to the end of the project, both for requirements (including changes) Are consistent in their perceptions.

This may be a bit abstract, we can take an example to illustrate.

For example, the requirement analysis of the initial stage of the project has a description: "The application system can automatically generate the corresponding PDF report file for each user's data according to the predefined personalized template, and send it to the electronic mailbox which is preset in the user's information." ”

In response to this requirement, the developer found a plug-in that automatically generates a PDF file that reads an XML template and then generates a PDF file based on the incoming data. After a while, the function is done, the user's project manager looked at the generated pdf feel good, the project goes well.

However, to the stage acceptance, the user organized a period of trial, the function of everyone feel dissatisfied, because ordinary users will not edit the XML template, feel very troublesome, and prone to formatting errors. At this point, users should provide an editing interface, so that users can see the way to edit the template, which is also very natural.

Here's the problem: developers think it's a change in demand, and there's no mention of it in the requirements. This will cause the project's progress, budget needs to be adjusted, and perhaps some people will ask users to increase development costs. And the user will think that this is the development of the work is not done well, how can you do a function to let users edit the XML themselves? It's hard to find a user who knows what XML is in 100 users, let alone edit it. So the two sides will be entangled on this issue. And this is only a small piece of the whole project needs, one leaf and know autumn, the other part of the problem is certainly indispensable.

In the end is the user unreasonable, or developers lazy? In fact, no, I think the problem is not defined in the definition of stringent requirements. If the developer communicates with the user about the format of the template during the requirements analysis process, users will be able to define template editors ' needs in the first time, so the requirements may be as follows: "The application system can provide PDF template editing, allowing users to customize the personalization template in WYSIWYG mode, According to the template, the corresponding PDF report file is automatically generated for each user's data and sent to a preset email address in the user's information. "Such demand is more rigorous, and the issue of later controversy is reduced." Of course, you can also find some of the less rigorous areas, such as "regular" what is the concept of fixed once a week or once a month, or users can customize, or to provide a few standard options for users to choose? All these ambiguous definitions are important in the process of demand analysis. Unless you have a good grasp of its uncertainty and its possible worst results, ignoring it will cause problems in the future for the project.

To summarize my idea: in the project, the user's dictionary is a document, revenue, reports, audits, and so on, while the developer's dictionary is key values, indexes, buttons, events, and requirements analysis is like a translator, the language of the user and the language of the developer together, so that both sides understand each other's meaning accurately, So that both sides really understand each other's thinking before starting the development work.

For the key factors in the requirements analysis, my own experience mainly has the following three points:

A deep understanding of business

The requirements analyst needs to have a very deep understanding of the user's business. A very deep understanding is that you can talk to the user's management about their business problems. If the financial products do not understand the risk control, do not know how to do the forum SEO, do personnel systems do not understand organizational behavior, how can have a profound understanding of the business?

Someone saw here to say, the user told me to understand what needs to do the function on the line, I to his industry understand so deep what is necessary? I want to say is that the need to do analysis is also divided into many levels, the higher the level, the need to understand the business more deeply.

Let me give you another example. A project to develop a business management system, the customer is an enterprise group, subordinate a lot of branches, are in many products line business, the group of branch business management disunity problem is very headache. The previous practice was to fax each product line's business report to the group at the end of each month, then the group carried out the business statistics. Now the customer demand is that in each branch of the deployment of a set and the same business management system, and in the group's platform to do a data escalation module, so that each branch can be from their own system to export the electronic version of data and to the group, thereby increasing the efficiency of reception and statistics.

"Also can" demand analysis can be accurate description of this requirement, rigorous definition, so that developers develop user satisfaction function. "Better" needs analysis can be further, and users to explore whether a large set of systems can be made, the branch can not report to the group at any time to see the business situation of each branch, so as to eliminate the problem of false cover-up data. "Better" requirements analysis may be discussed with the user to realize the matrix of business management through the support of information system, to improve the group's ability to manage the various lines of business without changing the organizational structure (because the organizational structure problem is beyond the scope of the requirements analysis, or even beyond the project range), To better implement the group's strategy for each product line.

There may be a "better" business analysis, but you can see that the deeper the business analysis results for the user, the greater the user's acceptance of the entire development team. This is important for the success of the project. If the customer is very grateful to you put forward to allow him to strengthen the business control ability of the plan, he will and you are entangled in the menu color enough to look good?

Ii. Full and user communication

Start by figuring out which users you have and how they relate to each other. There is an old saying called tune, and there is conflict between the views of the users. For example, executives want to collect more data the better, now can not be used in the future may be a data mining tool suddenly have the magic of the magic is also possible; the first line of users responsible for collecting data, of course, want the less data the better, as long as they are enough. Some business units do not want their business data to be known by too many people, and some projects may even cause some departments to lose power and some leaders lose positions. So in a project, there are always a variety of voices in the requirements discussion. Behind the sound is the position, the position behind is the interest. Inexperienced demand analysts can easily get lost in these sounds, and the final demand is Sibuxiang, which is what some users want to see.

What about this time? Old code farming I have a ancestral secret recipe: To find the user's biggest leader to discuss the overall idea of the project, and then according to the views of the big leaders to screen the user needs, and the general leadership of the idea of the obvious conflicts are thrown aside, to meet the needs of the big leadership thinking fully refined. What do you mean, big leader? Not the IT manager, the director of information, the customer the project manager and so on, but can decide and the project related to the business issues, such as the personnel system, the leadership is at least the director of manpower, to do the financial system is at least the financial controller, of course, to let the top leaders actively participate in the better. The process of discussing with the big leader is not only the process of understanding the thinking of the big leaders, but also the process of screening the needs, and more importantly, obtaining the support of the big leaders. With the support of the big leaders, and then the meeting, under the noisy, you can be calm, confident.

Someone may have to whisper: The big leader you want to see, who do you think you are? This is also linked to the first question I just talked about, the depth of business understanding. When the project starts, the general routine is to interview the project team, and you will leave an impression on the big leaders. If you open your mouth is a database, a form, Java framework What, the big leader and you have no intersection, naturally don't bother to see you, if you can talk about the biggest competitors in this project related business areas have advantages and disadvantages, foreign business control experience and so on, you may often become a big leader of the guest. So the depth of business understanding is critical to project success.

There are many forms of communication with users, such as requirements seminars, high-level interviews, user discussions, and so on. I think we should do a lot of first-line users to discuss, ask a lot of questions, all the business links are thoroughly figured out, conveniently collect some forms and data as the basis for demand analysis. Then to do high-level interviews, to understand the overall thinking, strategy, goals, such as macro-problems. Demand seminars generally open late, mainly for some of the controversy is relatively large or unclear definition of issues, brainstorming, is actually a brainstorming method. In these discussions, the demand analyst should not just be a recorder, but should be more questions and suggestions, with their own ideas to inspire users, bold ideas to carefully verify. But also pay attention to respect the views of users, can not feel that users do not understand technology so I casually listen to the line, how to achieve the technology, and the user does not have much relationship, so often in the later will be problematic.

Third, have a deep technical background and rigorous thinking

Requirements analysis is a bridge between business and technology, and the requirement document is a commitment to the user. When writing requirements documents, it is necessary for the requirement analyst to have a considerable technical background to understand the implementation path, difficulty, and approximate workload of each requirement, and to describe it in a rigorous way that the business and technical staff can understand without ambiguity. Of course, this is based on the previous communication with the user (including the technical staff) fully.

Some demand analysis personnel technical background is not very strong, is not the need to do a bad demand analysis? It would be a good combination to have a strong developer behind you to discuss your needs with your partner and provide you with technical advice so that you can fully develop your understanding and communication skills.

Write a document to test the needs of the people's writing skills, sometimes a word, a word need to repeated, accidentally can dig their own pits, a bit of a lawyer feeling is not it? It is not easy to understand the business and technology, here I suggest more drawing, a picture sometimes can be thousands of words. What flowchart, Data flow diagram Ah, organization Chart Ah, user interface diagram Ah what, can draw the place on more drawing, picture plus text, the reader's understanding is not easy to run deviation.

Finally, the requirements of the document finished, remember to print out, a core user to a, tell a few days can propose a change of opinion, only one time will form the initial requirements of the final version, and then change to take the change control process. Print a few more archived, the last more than one page signed confirmation page, so that all the users receive the requirements of the document final signature confirmation, and finally to the user side of the project manager to sign. A signature-confirmed archive can be used as a basis for future changes in requirements.

Some people say that the other project manager signed the line, why should all the core users to sign it? Because leaders are very cautious in signing. If he does not need to sign, he takes the demand to flip two to the drawer and throw it, he will not look at it carefully. But if he is required to make a change after three days, there is no change of opinion on the signature approval, this is different. He would look carefully and give his opinion seriously, because very few people would sign on something they didn't see carefully, right? This is also to help you examine in advance the definition is not rigorous, the future is likely to produce controversial content. So through this process, you can let the core users of the understanding of the requirements and development team for a synchronization, the real formation of a benchmark requirements.

About the experience of demand analysis, I say so much. His level is limited, nagging for so long, also do not know how many useful things, but also asked the reader to correct me. Finally, I have an idea, demand analysis is the bounden duty of the project manager, if the demand is very complex need a team, the project manager must be the core staff of the team. About Project Management I also have some experience, have time to write a little thing, Bo readers a smile just. You reader, foresee the funeral, and listen to decomposition.

The Writer: bole online-old code agriculture

This article link: http://blog.jobbole.com/49332/

[Reprint must be marked in the text and retain the original link, translation links and translators and other information. ]