Broadly speaking, demand analysis includes a series of demand items such as demand acquisition, analysis, specification, change, verification and management.

Demand analysis in a narrow sense refers to the process of demand analysis and definition.

cause

Requirements analysis is to analyze what the needs of software users are. If a lot of manpower, material resources, financial resources and time are invested, but no one wants the developed software, then all the investment will be in vain. If you spend a lot of energy developing a software, but in the end it doesn't meet the requirements of users and you have to re-develop, this kind of rework is heartbreaking (I believe everyone has experience). For example, users need a linux software, and you neglected the running environment of the software in the early stage of software development, forgot to ask the user this question, and took it for granted that you were developing software for windows. When you worked hard to develop it and submit it to users, you found something was wrong. At that time, you wanted to cry and find a piece of tofu to die.

Requirement analysis is important because it plays a decisive, directional and strategic role and it plays an important role in the process of software development. Everyone must pay enough attention to demand analysis. In the development of large-scale software systems, its role is far greater than programming.

work

In short, the task of requirements analysis is to solve the problem of "what to do", that is, fully understand the needs of users and accurately express the accepted needs of users.

process

The work in the requirement analysis stage can be divided into four aspects: problem identification, analysis and synthesis, specification formulation and evaluation.

Problem identification: It is to understand the software from the system point of view, determine the comprehensive requirements for the developed system, and put forward the realization conditions of these requirements and the standards that the requirements should meet. These requirements include: functional requirements (what to do), performance requirements (what indicators to achieve), and environmental requirements (such as model and operating system). ), reliability requirements (failure probability), security requirements, user interface requirements, resource usage requirements (memory and CPU required for software operation, etc.). ), software cost consumption and development schedule requirements, as well as the prediction of the possible goals of the system in the future.

Analysis and synthesis: gradually refine all software functions, find out the relationship among system elements, interface characteristics and design restrictions, analyze whether it meets the requirements, eliminate unreasonable parts and increase needed parts. Finally, the detailed logical model of the system to be developed (the model of what to do) is given by synthesizing the system solution.

Formulate specifications: that is, prepare documents, and documents describing requirements are called software requirements specifications. Please note that the result of the requirements analysis phase is the requirements specification, which will be submitted to the next phase.

Review: Evaluate the correctness, completeness and clarity of functions and other requirements. Only after the approval can the next stage of work be carried out, otherwise the demand analysis will be carried out again.

way

There are many methods of requirement analysis, and only the prototype method is emphasized here. Other methods, such as structural method and dynamic analysis, have never been used and will not be discussed here.

Prototype method is very important. Prototype is an early operational version of the software, which realizes part or all of the functions of the target system.

Prototype method is to build a rough system as soon as possible and realize some or all functions of the target system. However, the system may have defects in reliability, friendly interface or other aspects. The purpose of constructing such a system is to examine the feasibility of a certain aspect, such as the feasibility of algorithm, the feasibility of technology or whether it meets the needs of users. For example, in order to see whether it meets the requirements of users, we can use some software tools to quickly build a prototype system, which is just an interface, and then listen to the opinions of users and improve this prototype. The future target system will be developed on the basis of the prototype system.

There are three main types of prototypes: exploratory, experimental and evolutionary.

Exploratory: The purpose is to find out the requirements for the target system, determine the expected characteristics, and explore the feasibility of various schemes.

Experimental type: used to check whether the scheme is appropriate and the specification is reliable before the implementation of large-scale development.

Evolutionary type: the purpose is not to improve the specification, but to make the system easy to change, and gradually evolve the prototype into the final system in the process of improving the prototype.

There are two different strategies when using prototype method: discard strategy and append strategy.

Abandonment strategy: first, establish a model system with simple function and low quality requirements, and modify it repeatedly to form a better idea, so as to design a more complete, accurate, consistent and reliable final system. After the system was built, the original model system was abandoned. Exploratory and experimental types belong to this strategy.

Additional strategy: first build a model system with simple function and low quality requirements as the core of the final system, and then gradually add new requirements through continuous expansion and modification to develop into the final system. Evolutionary type belongs to this strategy.

20 rules of demand analysis

Customers need good ways to communicate with developers. Here are 20 rules that customers and developers can understand by looking at the following. In the case of disagreement, mutual understanding of their respective obligations can be reached through consultation, so as to reduce future friction (for example, one party makes a request and the other party is unwilling or unable to meet it).

1. Analysts should use expressions that conform to customers' language habits.

Requirements discussion focuses on business requirements and tasks, so use terminology. Customers should teach analysts related terms (such as purchase price, printed goods and other purchase terms), but customers don't have to know the terms of computer industry.

2, analysts should understand the customer's business and goals.

Only when the analyst has a better understanding of the customer's business can the product better meet the demand. This will help developers to design excellent software that truly meets the needs and expectations of customers. To help developers and analysts, customers can consider inviting them to observe their own workflow. If switching to the new system, developers and analysts should use the old system, which will help them understand how the system works, its process and what can be improved.

3. Analysts must write software requirements reports.

Analysts should sort out all the information obtained from customers to distinguish business requirements from specifications, functional requirements, quality objectives, solutions and other information. Through these analyses, customers can get a "demand analysis report", so that developers and customers can reach an agreement on the content of products to be developed. Reports should be organized and written in a way that customers think is easy to read and understand. Customers should review this report to ensure that the contents of the report accurately and completely express their needs. High-quality "requirements analysis report" helps developers to develop the products they really need.

4. Ask for an explanation of the results of the required work.

Analysts may use various charts as a supplementary explanation to the textual "requirements analysis report", because the working diagram can clearly describe some aspects of system behavior, so the charts in the report are of great value; Although they are not too difficult to understand, customers may not be familiar with them, so customers can ask analysts to explain the function of each chart, the meaning of symbols and the results of requirements development work, as well as how to check whether there are errors and inconsistencies in the charts.

Developers should respect the opinions of customers.

If users and developers can't understand each other, there will be obstacles in the discussion of requirements. * * * cooperation can make everyone "listen". Customers who participate in the requirements development process have the right to ask developers to respect them and cherish the time they spend for the success of the project. Similarly, customers should also respect the efforts of developers for the same goal of project success.

6. Developers should put forward suggestions and solutions for requirements and product realization.

Usually, what customers call "demand" is a practical implementation. Analysts should try to understand the real business needs from these solutions, and at the same time find out the inconsistencies between the existing system and the current business to ensure that the products will not be ineffective or inefficient. After thoroughly understanding the things in the business field, analysts can propose quite good improvement methods, and experienced and creative analysts can also propose adding some valuable system features that users have not found.

7. Describe the use characteristics of the product

Customers can ask analysts to pay attention to the ease of use of the software while realizing the functional requirements, because these easy-to-use features or quality attributes can enable customers to complete tasks more accurately and efficiently. For example, customers sometimes require products to be "user-friendly" or "robust" or "efficient", but for developers, this is too subjective and has no practical value. The correct way is for analysts to understand the specific features of "friendly, robust and efficient" that customers want through inquiry and investigation, specifically analyze which features have negative effects on which features, and make a trade-off between the performance cost and expected benefits of the proposed solution to ensure a reasonable choice.

8. Allow the reuse of existing software components.

Requirements are usually flexible, and analysts may find that existing software components meet the requirements described by customers. In this case, analysts should provide some options to modify the requirements, so that developers can reduce the development cost and save time of the new system without strictly following the original requirements. Therefore, if you want to use some existing commercial components in your products, and they are not completely suitable for the features you need, then a certain degree of demand flexibility is extremely important.

9. It is necessary to make a true and reliable assessment of the cost of the change.

There are different options. At this time, it is necessary to evaluate the impact of demand changes to help business decisions. Therefore, the customer has the right to ask the developer to give a true and credible evaluation through analysis, including impact, cost, gains and losses, etc. Developers can't arbitrarily exaggerate the evaluation cost because they don't want to implement changes.

10, and get a system that meets the customer's function and quality requirements.

Everyone wants the project to be successful, but this requires not only that the customer clearly tells the developer all the information about what the system does, but also that the developer clearly understands the trade-offs and limitations through communication, and must clearly explain your assumptions and potential expectations, otherwise, the products developed by the developer may not satisfy you.

1 1. Explain your business to analysts.

Analysts rely on customers to explain business concepts and terms, but customers can't expect analysts to be experts in this field, only let them understand your problems and goals; Don't expect analysts to grasp the subtle potential of customers' business. They may not know the common sense that customers take for granted.

12, take the time to explain clearly and improve the requirements.

Customers are very busy, but in any case, it is necessary for customers to take time out to participate in "brain summit" discussions, interviews or other activities to obtain demand. Some analysts may understand your point of view first, and then find that they need your explanation. In the process of refining requirements, please be patient with some requirements and repetitions, because this is a natural phenomenon in interpersonal communication and is extremely important for the success of software products.

13. Explain the requirements accurately and in detail.

It is difficult to write clear and accurate requirements documents. Because dealing with details is annoying and time-consuming, it is easy to leave vague requirements. But in the process of development, we must solve this ambiguity and inaccuracy, and the customer is the best person to make a decision to solve these problems, otherwise, we will have to rely on the correct guess of the developer.

This is a way to temporarily add a "pending" flag in the requirements analysis. Use this sign to indicate that places that need further discussion, analysis or information may sometimes be marked as "pending" because a special requirement is difficult to solve or no one is willing to deal with it. Customers should try to be clear about the content of each requirement so that analysts can accurately write them into the "Software Requirements Report". If customers can't express it accurately at the moment, they usually need to use prototype technology. Through prototype development, customers and developers can repeatedly modify and constantly improve the definition of requirements.

14, make a decision in time

Analysts will ask customers to make some choices and decisions, including handling methods proposed by multiple users or choosing a compromise between quality characteristics conflict and information accuracy. Customers who have the right to decide must treat all this positively, deal with it as soon as possible, and make a decision, because developers usually have to wait for customers to make a decision before they can act, which will delay the progress of the project.

15. Respect the developer's needs, feasibility and cost assessment.

All software functions have their costs. Some customers want product features that may be technically unfeasible or costly to implement, while others try to achieve performance that is impossible in the running environment or try to get some data that is simply not available. Developers will make negative comments on this, and customers should respect their opinions.

16. Prioritize requirements

Most projects don't have enough time or resources to realize every detail of the function. Deciding which features are necessary and which are important is the main part of requirements development, which can only be set by customers, because it is impossible for developers to decide the priority of requirements according to customers' views; Developers will provide information about the costs and risks of each requirement for you to prioritize.

Under the limitation of time and resources, whether or how many required functions can be completed should respect the opinions of developers. Although no one wants to see what they want not realized in the project, they should face the reality after all. Business decisions sometimes have to narrow the scope of the project or extend the construction period, increase resources, or find a compromise on quality according to priorities.

17, review requirements documents and prototypes.

Customer review requirements documents are an opportunity to provide feedback to analysts. If the customer thinks that the "demand analysis report" is not accurate enough, he should inform the analyst as soon as possible and provide suggestions for improvement. A better way is to develop a prototype for the product first. In this way, customers can provide more valuable feedback information to developers, so that they can better understand your needs; Prototype is not an actual application product, but developers can transform and expand it into a fully functional system.

18. If the demand changes, please contact immediately.

Constant demand changes will have a serious adverse impact on the quality products completed within the scheduled plan. Change is inevitable, but in the development cycle, the later the change appears, the greater its impact; Changes will not only lead to costly rework, but also delay the construction period, especially when new functions need to be added after the completion of the general structure. Therefore, once the customer finds it necessary to change the requirements, please inform the analyst immediately.

19. Follow the development team's process of handling requirements changes.

In order to minimize the negative impact of changes, all participants must follow the project change control process. This requires not giving up all the proposed changes, analyzing and comprehensively considering every needed change, and finally making appropriate decisions to determine which changes should be introduced into the project.

20. Respect the requirements analysis process adopted by developers.

The most challenging thing in software development is to collect requirements and determine their correctness, and the method adopted by analysts is reasonable. Perhaps customers think that the process of collecting requirements is not cost-effective, but please believe that the time spent on requirements development is very valuable; If you understand and support the technology used by analysts to collect and write requirements documents and ensure their quality, the whole process will be smoother.

What does "requirement confirmation" mean?

Signing the "requirement analysis report" is usually considered as a sign that the customer agrees with the requirement analysis. However, in practice, customers often think that "signing" is meaningless. "They asked me to sign under the last line of the requirements document, and I did, otherwise these developers wouldn't start coding."

This attitude will bring trouble. For example, when customers want to change their requirements or are dissatisfied with their products, they will say, "Yes, I signed the requirements analysis report, but I didn't have time to read all the contents. I believe you, but you let me sign it. "

The same problem will happen to analysts who only regard "signature confirmation" as completing the task. Once there is a demand change, he points to the Demand Analysis Report and says, "You have signed the demand, so these are what we developed. If you want something else, you should tell us earlier. "

Both of these attitudes are wrong. Because it is impossible to know all the requirements in the early stage of the project, and there is no doubt that the requirements will change, signing the "requirements analysis report" is the correct way to terminate the requirements analysis process, so it is necessary to understand what signing means.

The signature of the "Requirements Analysis Report" is based on the baseline of a requirements agreement. We should understand the signature as follows: "I agree that this requirements document expresses our understanding of the software requirements of the project, and further changes can be made on this baseline through the change process of the project definition. I know that this change may lead us to renegotiate issues such as cost, resources and project tasks. " Reaching a certain understanding of demand analysis will make it easy for both parties to tolerate future frictions, which come from project improvement and demand errors or new requirements of the market and business. Requirements confirmation dispels the fog, reveals the true face of requirements, draws a clear end to the initial requirements development work, and helps to form a continuous good customer and developer ONT >;