根据《软件文档管理指南》GB/T16680-1996，以下关于文档评审的叙述，（）是不正确的。A、需求评审进一步确认开发者和设计者已了解用户要求什么及用户从开发者一方了解某些限制和约束B、在概要设计评审过程中主要详细评审每个系统组成部分的基本设计方法和测试计划，系统规格说明应根据概要设计评审的结果加以修改C、设计评审产生的最终文档规定系统和程序将如何设计开发和测试以满足一致同意的需求规格说明书D、详细设计评审主要评审计算机程序、程序单元测试计划和集成测试计划

《软件文档管理指南》（GB/T16680—1996）有关“文档评审”的内容如下：
需求评审进一步确认开发者和设计者已了解用户要求什么，及用户从开发者一方了解某些限制和约束。需求评审可能需要一次以上产生一个被认可的需求规格说明。基于对系统要做些什么的共同理解，才能着手详细设计。用户代表必须积极参与开发和需求评审，参与对需求文档的认可。
设计评审通常安排两个主要的设计评审，概要设计评审和详细设计评审。
在概要设计评审过程中，主要详细评审每个系统组成部分的基本设计方法和测试计划。系统规格说明应根据概要设计评审的结果加以修改。
详细设计评审主要评审计算机程序和程序单元测试计划。
设计评审产生的最终文档规定系统和程序将如何设计、开发和测试。应选择D。

根据GB/T 16680－1996《软件文档管理指南》，需求评审产生一个被认可的需求规格说明。
用户代表必须积极参与开发与需求评审，参与需求文档的认可。
因此，选项B只有同行评审是不够的，用户代表必须参与评审。

《软件文档管理指南》（GB/T16680—1996）有关“文档评审”的内容如下：

需求评审进一步确认开发者和设计者已了解用户要求什么，及用户从开发者一方了解某些限制和约束。需求评审可能需要一次以上产生一个被认可的需求规格说明。基于对系统要做些什么的共同理解，才能着手详细设计。用户代表必须积极参与开发和需求评审，参与对需求文档的认可。

设计评审通常安排两个主要的设计评审，概要设计评审和详细设计评审。

在概要设计评审过程中，主要详细评审每个系统组成部分的基本设计方法和测试计划。系统规格说明应根据概要设计评审的结果加以修改。

详细设计评审主要评审计算机程序和程序单元测试计划。

设计评审产生的最终文档规定系统和程序将如何设计、开发和测试。应选择D。

GB/T12504-2008《计算机软件质量保证计划规范》第四小节规定：4.5评审和检査必须规定所要进行的技术和管理两方面的评审和检査工作，并编制或引用有关的评审和检査规程以及通过与否的技术准则，至少要进行下列各项评审和检査工作：4.5.1软件需求评审software requirements review在软件概要设计结束后必须进行概要设计评审，以确保在软件需求规格说明书中所规定的各项需求的合适性。4.5.2概要设计评审preliminary design review在软件概要设计结束后必须进行概要设计评审，以评价软件设计说明书中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。4.5.3详细设计评审detailed design review在软件详细设计阶段结束后必须进行详细设计评审，以评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性。4.5.5功能检査functional audit在软件释放前，要对软件进行物理检査，以验证程序和文档己经满足在软件需求说明书中规定的所有需求。4.5.6物理检査physical audit在验收软件前，要对软件进行物理检査，以使程序和文档己经一致并己做好了交付的准备。4.5.7综合检査comprehensive audit在软件验收时，要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检査，以验证代码和设计文档的4.5.8管理评审management reviews要对计划的执行情况定期（或按阶段）进行管理评审；这些评审必须由独立于被评审单位的机构或授权的第三方主持进行。

根据GB/T 14394-2008《计算机软件可靠性和可维护性管理》的内容，设计评审包括以下内容：①可靠性和可维护性目标分配；②可靠性和可维护性设计方案；③设计分析，关键成分的时序，估计的运行时间，错误恢复及相关性能要求；④测试原理、要求、文档和工具。

既然是功能检查、物理检查和综合检查，那么就必须有一个完整的系统才能评审，所以要在集成测试阶段结束后进行。需求分析阶段、软件设计阶段时间段太早了，验收测试阶段结束后太晚了。

评审小组可由业务人员，开发人员和用户等组成，包括用户，A选项描述错误。

根据《软件可靠性和可维护性管理GB/T14394—2008》，与软件可靠性和可维护性有关的具体评审要求有：概念评审、需求评审、设计评审、测试评审、安装和验收评审、软件用户手册评审。

根据GB/T 16680《软件文档管理指南》，软件文档分为：开发文档（描述开发过程本身）、产品文档（描述开发过程的产物）、管理文档（记录项目管理的信息）。基本的开发文档是：可行性研究和项目任务书、需求规格说明、功能规格说明（包括程序和数据规格说明）、开发计划。基本的产品文档是：培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。管理文档是：开发过程的每个阶段的进度和进度变更的记录、软件变更情况的记录、相对于开发的判定记录、职责定义。详细评审主要评审计算机程序和程序单元测试计划。文档的质量可以按文档和的形式和列出的要求划分为四级。最低限度文档（1级文档）：1级文档适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。内部文档（2级文档）：2级文档可用于在精心研究后被认为似乎没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。工作文档（3级文档）：3级文档适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。正式文档（4级文档）：4级文档适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要4级文档。4级文档应遵守GB8567的有关规定。质量方面需要考虑的问题既要包含文档的结构，也要包含文档的内容。软件产品的所有文档都应该按规定进行签署。必要时进行会签，签署不允许代签。

根据《软件可靠性和可维护性管理GB/T14394—2008》，与软件可靠性和可维护性有关的具体评审要求有：概念评审、需求评审、设计评审、测试评审、安装和验收评审、软件用户手册评审。