How to do demand analysis

First, how should we do demand analysis?

Requirements analysis can't be done overnight, it should run through the whole development cycle, constantly analyzing and confirming the process. This is the requirement feedback advocated by agile development. Agile development believes that it is impossible to solve all requirements in the requirements analysis stage, so the whole process from design, development, testing to final delivery to customers should constantly communicate with customers with the results of development and get feedback in time. Only in this way can we correct the deviation of demand understanding in time and ensure the success of the project.

Second, how should we do demand research?

1. First meeting.

After deeply understanding the requirements put forward by customers, we use our professional knowledge to propose a more reasonable and operable solution than the original requirements of customers, so that customers feel that what you said is exactly what they want. If you can do this, customers will not only accept your proposal, but also feel that you are professional, and your image in the eyes of customers will be improved invisibly, so that you will have more opportunities to put forward feasible solutions conducive to development and reduce the risk of development. This will undoubtedly form a virtuous circle, but it is not easy to do this. There is no doubt that the initial performance of contact with customers plays an extremely critical role.

(1) The top leaders are concerned about the macro goals, so we should talk to the top leaders about the software R&D goals, macro statistical reports and decision support functions.

(2) Middle-level leaders are concerned about specific benefits, that is, the benefits brought by software to information management of various departments. Therefore, middle-level leaders are the demand decision makers of various business processes and functional modules. They care about the definition of functions, the connection of business processes and the design of query reports, but they are not very concerned about some specific operations and the details of some specific business processes.

(3) Grassroots personnel are the operators of every business process and the real users of future software. They are domain experts who really understand the business requirements of the software you want to develop, and they are the key objects of your demand research. Grassroots personnel are often limited by their own vision and may only know a very narrow scope of work. Therefore, we need to work hard to find real experts with extensive business, rich experience and a certain overall situation. In addition, they are real users of future software, and their participation will make them loyal supporters of future software implementation, which will be of great benefit to other operators. They care about the details of every operation.

As the saying goes, everything is difficult at the beginning. If you are always confused at the beginning of a project, here are three suggestions for you:

1) Establish a good professional prestige;

2) Conduct detailed role analysis and bring representatives of all parties to the meeting accordingly;

3) Set goals and plans from a macro perspective. The next work is to establish contact with all parties' codes, visit them one by one, and conduct demand research step by step.

Visit.

Demand research is not a one-off event, but a work that lasts for months or even years (if the project has post-maintenance). In this long time, we need to rely on the help of customers to master the real and reliable business needs step by step. Not only that, technology is always unsatisfactory and even impossible to achieve. We need customers' understanding and tolerance, which requires good customer relations. Nevertheless, we can't always expect all our customers to cooperate with us, and it is inevitable that some people will hinder the development of many projects.

3. Seminar.

(1) Due to the limitation of business personnel themselves, it is impossible to fully grasp the details of all business areas, and familiar parts and unfamiliar parts always exist.

Points. Dividing business groups can allow business people to participate in discussions within their most familiar business scope, which can effectively improve the quality of business discussions;

(2) Centralized business discussion and decentralized business discussion;

(3) Effectively restrain individual differences and organize thematic discussions in modules.

4. Business discussion

In the process of demand analysis, the biggest problem for customers is that they can't put forward the correct demand, which is manifested in several forms:

(1) Because they don't know the software, customers can't ask for it, and they don't know what the software will look like in the end. At present, this kind of customers can only describe the way of manual management in the process of demand discussion, and I don't know how the computer will manage it.

(2) You can put forward some business requirements, but when the software is produced in front of you, the requirements will change. This kind of customers can skillfully use computers and have a clear understanding of information management. Their business requirements should be inseparable as a whole. However, because there is no physical object, some specific operations in the software are not fully thought out.

(3) Be able to put forward business requirements in great detail, and sometimes even put forward what to do. This kind of customers have participated in many software information construction, and some are even semi-professionals in software development. However, the business requirements they put forward are too specific, and even how to realize them is said, but sometimes these are not the best design schemes, which may be technically difficult to achieve, and some are even too idealistic to achieve.

Solution:

Business domain analysis: what is the customer's existing business process and what operations are there? What are the things and terms in the customer's business, how to define them, and what is the relationship between them? What is the purpose of each operation of the customer, why do you do it, and what does the manual report show?

Question?

(1) When we do requirements analysis, we should not only stay in the software itself, but also broaden our horizons and extend to those fields related to this business.

(2) Among all the original requirements put forward by customers, those related to business realization are invalid requirements, which can only be used as our reference.

(3) There are still some requirements that are technically difficult or impossible to achieve. We should patiently persuade and guide our customers and propose a more reasonable plan for them.

(4) Demand analysis is not a simple collection activity, but an analysis activity based on a large number of business analysis and technical feasibility analysis. Only software development based on this analysis can ensure the correctness of requirements and the controllability of changes.

Step 5 cycle

In the first stage of demand analysis, we need to discuss with customers repeatedly for a period of time, and this process is often such a cyclical process: demand capture->; Demand integration->; Requirements verification->; Demand capture ...

(1) Demand capture: it is an activity that we hold a seminar with our customers to discuss demand. Customers may describe their business processes, and then we draw a simple process sketch on paper and record it in time; While describing the business, customers may repeatedly mention some business terms, inquire about the meaning of these terms and their relationship with other terms in detail, and draw a simple sketch with class diagrams or objects; While describing the business, customers will also put forward the functions that the software hopes to realize in the future, such as being able to display reports, export files and record them in the form of demand list. A function will have multiple requirements in the requirements list, and each requirement should be clearly described in 1 and 2 sentences within 20 words. Demand list is the most original demand put forward by customers. It is not mixed with any analysis and design, and it is the content that each of our functions must realize.

(2) Requirements collation: It is the process that the requirements analysts analyze and collate the discussion contents after the requirements seminar. First of all, the demand analyst should divide the functional modules and business processes of the whole system through the use case model. Use case model analysis is a process from coarse to fine, and this process is also a process that conforms to human thinking habits of understanding the world. First, draw a use case diagram for the whole system, design a use case scenario, and analyze these use cases in turn, such as use case description, process analysis, role analysis and so on. Of course, while analyzing the overall use case, we should also conduct overall role analysis, draw a role analysis diagram, conduct process analysis, and draw a process analysis diagram (which can be a traditional flowchart, an action diagram in UML, or even a simple schematic diagram). ), and then draw a use case diagram for each use case in turn on the basis of the overall use case diagram. In each use case diagram, multiple use cases will be divided into more details, and the analysis work such as use case description, process analysis and role analysis will be carried out in turn. Constantly improve this and that until we think that the requirements have been clearly described.

(3) Domain model: It is a description of related things, relationships and behaviors in the user's business domain, which is expressed in the form of object diagram and class diagram. The analysis of domain model by demanders, the depth of business understanding, the design of future software, and the function expansion, upgrade and evolution of software are of vital importance.

(4) Requirements verification: Requirements verification should run through the whole R&D cycle and show different forms in different periods. First of all, in the stage of requirements analysis, requirements verification is manifested as information feedback on whether the requirements are understood correctly. Demand analysts and customers sit together again and describe our arrangement and understanding of demand one by one, while customers correct some problems or describe them in more depth from time to time. We carefully record it, come back and sort it out, and wait for the next verification. In the later stage of requirements analysis, we can also make some simple prototypes to describe our understanding of requirements more vividly, which will make our communication with customers smoother. In the subsequent design and development stage, I

Scientists should do it in the form of iterative development. After each iteration, feedback the development results to customers. In this way, customers can promptly point out the deviation of our understanding of the requirements, or put forward the places where we are not satisfied with the design, so that our existing problems can be found and solved in time. The timely solution of the problem can minimize the cost of repairing the problem.

6. Demand capture

After in-depth analysis, we will find that the requirements spoken by customers are only the tip of the iceberg in the whole software requirements, and there are two types of requirements that we need to explore ourselves: the requirements that customers have not spoken and the requirements that customers have not expected.

(1) What are the hidden needs of customers? It's not that customers deliberately show off their officials and don't want to talk about it, but that they have agreed business rules in their business fields, which they take for granted, needless to say. However, as demanders who have just set foot in this field, they don't understand these rules. If we only record the requirements stated by the customer in a passive way, we will undoubtedly lose this part of the requirements, which is why the software will not be developed and delivered until the later stage of the project, but the customer says that it is not what I want and puts forward a lot of reasons for changing the requirements. We are required to constantly learn business knowledge in the whole process of demand analysis. At the beginning of the demand interview, I often don't talk to customers about demand, but talk to customers about business first. How do you operate it? What are the processes? Who will complete these operations? Why are you doing this? Note that of all these problems, the last one is the most important. All the operations and processes in the customer's business field have their own significance, reflecting their internal reasons and functions. Asking more questions can help us understand these areas in depth. Think from the customer's point of view, and then deeply understand why customers put forward business requirements.

(2) The other is the customer's unexpected demand: in the demand analysis stage, although the customer didn't think of it, the demand analyst is a professional in the field of software research and development, and they should find these requirements in advance through analysis on the basis of in-depth understanding of business areas and requirements. As requirements analysts, they should think from the customer's point of view, what our software should be designed to look like, and what is the real intention of each requirement. On this basis, the professional knowledge is used to organize, analyze and design. As I mentioned earlier, the original requirements described by customers are written in the requirements list, sorted, analyzed and designed by demand analysts, and finally formed into product requirements specifications (or product specifications) through use case analysis and domain modeling. First, talk to customers alone in some informal occasions to generate first-hand information, and finally put these requirements into more formal occasions, such as business seminars attended by various departments and users' representatives