What makes Acceptance Test acceptance time delayed?

During project creation, we have good plans and constantly strengthen risk tolerance ~~~ But in fact, when devolpment is finished, it's time to test and UAT. Generally, the time at this stage is much longer than the scheduled schedule or leaders think. The programmer receives the bug report and new changes again and again. Here, the new changes is of course a new modification. You can ask the customer to calculate the money, but the bug is not. The general range exception, null exception, branch, algorithm, and other real technical bugs in the code of an excellent programmer team are rare. The most common and most difficult to modify is that logic error and implementation are inconsistent with real requirements.

The biggest annoyance to the entire team is the inconsistency between implementation and real needs. Programmers complain that the requirement document is clearly written in this way, and I am doing this right. The demand analysts complained more. I wrote this clearly. Why did they make it look like that? That's what the customer said at the beginning. Why did they test it now? They didn't mean it, and it's almost completely different ?.......

Summarize the reasons for the inconsistency between implementation and requirements:
1. The requirement document is not clearly stated. This document contains two meanings: one is that the meaning of the requirement terms is vague, and the other is that the requirement information is incomplete. This leads to a large misunderstanding between analysts and designers. In addition, if a company has professional analysts and positions, they may immediately receive the requirements of the next project after analyzing a project, as a result, when the requirements need to be discussed and clarified during development, the analyst may not be able to fully determine the requirements or indicate errors.

2. The requirement mining is not deep, and the records fail to express what the customer really needs. This usually shows that when the customer obtains the product for testing, the customer does not have to look at it for a few minutes and says: how is this *** like this? This report needs to be added ***........

3. The analysts failed to guide the customer to unify the requirements of decision makers and actual operators. This is often the case. We completed the requirement analysis according to the customer's project owner's statement. In the end, UAT was basically input by the actual operator, so many operators began to express their own requirements in 7 bits and 8 bits. At this time, the customer's project owner showed a high level of respect for the quality of their subordinate opinions: this is what they use. Of course, they all say that, of course, they have to change it to that, what else do I buy ~~~~ Cloud

4. continuously discover problems and minor changes, so that if you finally want to query the final detailed requirements of a part, you may need to refer to N relevant documents. it is common that, even if everyone knows and can obtain these documents, it is better to ask a person, so ask the program manager, analyst, and project manager for the changed requirements, are they all confused about the changes? Even if he/she is clear, what is his/her expression?

The continuous extension of test and UAT has a great impact, and almost everyone you see is complaining. the leader began to be dissatisfied. Why did it take so long? The plan for putting people into the next project had to be changed. project costs keep increasing, and the total project order amount does not necessarily increase. programmers started to feel down in the bug-fix process, because the project has been dragging on for a long time, there are no new things to modify, and what will make everyone feel the same is that, the (implemented) changes. analysts are facing pressure, but many people will push their responsibilities to programmers and customers. project managers are the most suffering. one phenomenon may also occur: overtime, overtime, and overtime .....

How can we reduce the probability of such an event? Here we will list what you think 1 and 2:
1. Make sure that you keep the text description for the Requirement Description. Do not think that you will not write the descriptive requirements after using OOA and UML.

2. Each requirement should be brief and clear, with a single meaning and unique access.

3. Analysts should keep the requirement survey materials that have not been sorted out.

4. Analysts should try their best to understand the requirements in the same way as each of the analysts. Explanations, retelling, confirmation, and other means can be used.

5. It is recommended that analysts discuss and confirm the detailed design with the designer after the preliminary completion of the detailed design document.

6. Keep records and maintain Requirement documents. This is very important.