某企业软件开发人员的下列做法中，不正确的是( )A.计划根据同行评审、阶段评审的结果建立需求、设计、产品三条基线B.在需求分析规格说明书通过同行评审后建立需求基线C.建立需求基线没有包括用户需求说明书D.因用户需求有变更，故依据变更控制流程修改了需求基线

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

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

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要对计划的执行情况定期（或按阶段）进行管理评审；这些评审必须由独立于被评审单位的机构或授权的第三方主持进行。