软件评审的难点主要包括以下几个方面：
需求理解与分析
需求报告长且复杂：需求报告可能非常详尽，评审者需要花费大量时间才能完全理解需求。
需求不明确或矛盾：需求中可能存在不明确或矛盾的地方，导致评审者难以做出准确判断。
需求优先级不清晰：评审者可能难以确定需求的优先级，从而影响后续的开发和测试工作。
评审准备不足
缺乏充分准备：评审前没有足够的时间让评审者熟悉需求文档，导致评审效率低下。
检查单不完善：没有制定详细的检查单，导致评审过程中遗漏重要内容。
评审人员问题
评审员选择不当：找不到合适的评审员，或者评审员无法提出深入的问题。
评审员专业能力不足：评审员对行业和业务了解不够深入，或者对需求实现所需的技术架构不理解。
评审员主观性较强：评审过程中可能存在主观评价，影响评审的客观性和公正性。
评审过程控制
评审节奏难以控制：需求评审的节奏可能难以有效控制，导致评审时间过长或过短。
评审会议效率低：评审会议可能流于形式，缺乏有效的讨论和交流。
技术实现与验证
技术难点：在技术实现过程中，可能会遇到设备兼容性、通讯稳定性、数据安全性等挑战。
代码质量：代码评审过程中可能发现大量问题，需要团队成员具备扎实的开发经验和技术实力。
评审模式的选择
依赖经验：评审效果高度依赖于评审者的个人能力和责任心，难以标准化。
走过场：评审可能流于形式，主要由于团队对评审的重视程度不够。
依托检查清单：虽然检查清单可以提高评审的系统性，但过度依赖也可能导致忽视其他重要问题。
建议
充分准备：提前发放需求文档，留出足够的时间让评审者熟悉内容，并制定详细的检查单。
分层次评审：将用户需求分层次，逐层进行评审，确保每个层次的需求都得到充分讨论和验证。
选择合适的评审员：确保评审员具备相关领域的专业知识和经验，能够提出有深度的问题。
控制评审节奏：制定明确的评审计划和时间表，确保评审过程有序进行。
加强技术验证：在技术实现过程中，进行充分的测试和验证，确保软件的质量和稳定性。
多样化评审模式：结合依赖经验、走过场和依托检查清单等多种评审模式，提高评审的全面性和有效性。
通过以上措施，可以有效应对软件评审中的难点，提高评审的质量和效率。