15.5.1 需求分解与分配注意点

需求分解与分配注意要明确系统内、外接口定义，确保所有的功能需求都分配到物理部件，每个功能都要由一个物理部件来完成，将非功能需求分解分配到功能和物理部件，最终形成产品的设计需求。对需求的处理方式可有以下决策意见：

♢长期的、模糊的需求分发由市场分析人员进一步调查，收集与其市场规模、市场增长率、市场竞争程度和市场细分情况等相关的市场数据，描述新产品或新领域的机会；

♢中长期的、与现有产品相关的、清晰的需求分发由规划人员进一步分析需求，根据需求优先级，定期进行产品规划，调整和优化《路标规划》和《版本规划》；

♢拒绝：取消该需求，结束；

♢重新分析：若决策认为需求分析不充分，则返回给产品经理，要求重新进行需求分析；

♢发起新产品进行开发：对于已确定为新产品开发，由产品经理提出立项产品开发需求，提出立项申请给主管研发的副总裁。由主管研发的副总裁批准立项并提名项目经理，发起全新、衍生产品开发项目，走立项流程；

♢接受、纳入现有开发项目：由产品部更新并提供《产品需求规格书》，提请主管研发的副总裁批准，批准后由项目经理纳入现行开发项目，参考《变更控制流程》进行需求变更。在计划决策评审点之前，分发的需求通过增加到产品包需求文档中。在计划决策评审点之后，分发的需求需要通过需求变更流程进行处理，值得注意的是这种方式的分发会对产品开发造成较大的影响，公司应尽量避免或者减少这种路径。

15.5.2 需求分配评审

项目研发团队成员充分表达对分配给自己的需求的看法，评审分配的需求是否可行，适合用软件或硬件实现，清楚、可测试、完整、没有遗漏。值得注意的是，除了技术需求外项目研发团队成员也应评审非技术需求如时间、工作量、成本方面的协议、条件、条款，同时分析和分配系统需求小组对评审中发现的缺陷，进行必要的修改。

需求评审及需求分配的评审可以被看作是一种早期的测试工作，投入到有效评审的时间在后续的阶段中会得到百倍甚至千倍的回报。因此项目管理从计划开始就应该为评审配备充足的时间和人力和其他资源，并采取措施保证评审的实效性。评审的形式可依据项目的特点和规模选取，如单人复审、走查、审查。评审人员的选择应注重广泛代表性，但也要注意控制审核队伍的规模，避免同一场评审中重复出现代表同一职责小组或利益的人，使评审难以控制。