200人以上的专业团队开发2到3年时间。游戏项目的需求涉及到很多内容，包括游戏类型、界面类型、引擎、游戏性等。
游戏项目的需求文档最初来源于策划案，内容包括剧情创意、玩法、美术风格等。结合游戏硬件和软件环境等因素，被分解生成《游戏功能描述书》，包含众多内容，若用整篇的文档来指导开发和测试工作，很容易引起任务分配的混乱;当发生需求变更时，也很难追溯历史版本。TechExcel从实践中提炼出一个行之有效的解决方法-用规范点(Specification，以下简称Spec)量化需求，正规表达每一个功能单元。只需打开《游戏功能描述书》的WORD文档，就可以利用插件，将其中的功能单元逐条地复制出来，在需求管理系统DevSpec中直接生成Spec。相对于需求，Spec是更面向技术人员的语言。
有序管理需求变更
在实际项目中，实现需求变更的成本随着开发进度呈指数级增长。需求变更的流程化管理能保障正常的开发进度，将变更及时反应到开发测试部门。
以下描述的是一个典型过程(如图1)。一项变更请求在需求管理系统中被提交后，与之关联的各个部门，如市场、程序、美术、测试等，都会有相关人员接到系统通知而介入。他们将组成评估团队，根据实施难度、周期、费用、对其他机制的影响等指标，对该变更进行全面考察和评估。在理想的游戏研发管理平台中，需求管理与所有规划、开发、测试管理过程相集成。因此，需求的正规表达Spec，以及围绕Spec正在或将要进行的开发任务和测试任务，都能被纳入综合考虑的范畴，便于评估团队估算该变更造成的"牵一发而动全身"的潜在影响。有时，还要结合商业需求进行考量，为了赶上最佳发布时机，有些变更将被拒绝。这个过程由独立的工作流控制，通常包括请求、复查、讨论、调整、批准和拒绝等状态，只有具备权限的项目成员才能改变状态。按照预设的流程，各方审批全部通过后，该变更才能被接受。
变更请求被批准后，与之相关联的开发、测试任务都会在系统中被一一标记出来，以提醒程序和测试部门的相关负责人，引发这些任务的需求已经变更，请他们做出相应的调整处理。在系统中跟踪这些任务的进展，可以实时掌握该变更的落实情况。变更完成后，也可以核算它对开发周期和费用的实际影响，与评估时的预测相对比，找出差异原因，为将来更准确地评估提供参考。
需求指导项目规划与执行
纵使项目最初都有比较全面的计划，延期仍然会时常发生，即便是在管理机制比较成熟的欧美游戏公司，跳票也不可避免。通常情况下，导致跳票主要有以下几点原因：功能设计规划过多，很多又无法删除，如不增加开发时间，游戏几乎不能完成;缺乏有经验的管理或开发人员，不能准确估计工作量;任务执行缺乏规范，开发人员随意更改功能设计，影响整体进度;过高的人员流动率，导致知识的流失，任务不能及时跟进。针对以上问题，只要从量化需求入手，有序管理需求变更，用正规表达、可量化的Spec来指导项目规划、编程和测试，就能把风险降到最低。
基于结构化的Spec集合，可以将项目分解为多个子项目，将Spec直接分配到各自对应的子项目中，以此来规划和估算子项目的工作量。项目管理人员为每个子项目分配资源，安排优先顺序，确定项目里程碑。在游戏项目中，不同部门协作异常紧密，因此子项目间的优先顺序显得尤为重要。例如，游戏音效制作与程序开发之间的相关度看似并不非常紧密，但若音效人员不实际感受游戏，很难体会玩家心情，也就难以创作出应景的音效。
在项目执行时，可以为每一个Spec产生出一系列开发任务。自定义的工作流机制确保每一个任务从提交到最终解决的生命周期都严格符合业务流程，保证任何时刻都有唯一的负责人、状态和截止日期。这样，不仅能规范游戏制作的过程，还能降低人员流动带来的风险。任务的流转及相关知识文档，如源代码、美术资源等，都得到系统完整的记录，还能与任务关联，便于追溯。一旦有人离开项目，接替的人员能够查看任务和文档信息，迅速弥补人员空缺。
以上所述的需求管理经验，虽然是从游戏行业的实践中总结得出，却不囿于游戏行业，项目复杂度较低的一般软件企业也可以借鉴。