1. 引言
《需求启动会议》作为需求过程所涉及文档的一部分提出。文档内容主要是一些具备可操作性的方式方法，并且给出实施依据。目的是在具体的软件项目过程可以借鉴其中的内容并且高效地进行应用。
2. 会议背景
项目的甲乙双方签定合作合约后，就进入项目的启动阶段。项目启动阶段的核心工作是完成需求，其中项目甲方是指客户方，项目乙方为开发方。
3. 常见问题
项目甲方的积极参与对构造需求是非常关键的。实际操作中要做到这点存在着一些问题：甲方自身的提供需求的能力以及他们是否愿意积极地参与进来。我们可能会说，“有时要找出这些人有一定困难”，“要让他们参与进来不是很好办”。如果项目甲方不能或不愿意参与，这就意味着项目失去了内部支持这条成功的条件。
4. 会议内容
事实上，提供需求、解释需求、指定需求和排列需求优先级是项目甲方的职责所在。此外，项目甲方有权利要求开发队伍投入时间去辨别和理解这些需求。项目甲方负责提供需求，开发组负责理解和实施。召开需求启动大会，旨在动员涉众人员关注需求，积极地参与到需求的过程中来。使得对需求的重要性有足够的认识，同时也为项目甲乙双方在以后相互协作过程中有一个好的沟通平台奠定好基础。
会议主要内容是：
1、 开发方简要阐明需求的重要性。开发方必须使用通俗易懂的语言说明需求是项目分析、设计和实施的依据，用户只有把需求描述清楚，而且开发人员真正了解了需求，项目成功才有保证等内容。以下列举项目成败与需求的相关数据依据（可以根据实际情况更新）：
ü 失败
Ø 缺乏用户输入(13%)；
Ø 不完整的需求(12%);
Ø 不断变化的需求(12%);
ü 成功
Ø 用户介入(16%) ；
Ø 有效的管理(14%) ；
Ø 清晰完整的需求(12%) ；
2、 开发方简要阐明完成需求的一般过程。主要是描述在需求过程中需求的的各个阶段以及开发方一般采取什么样的需求手段、方法。具体内容请参照其他相关文档。
ü 需求收集
Ø 报表，表单
Ø 面谈，会议
Ø 现场业务参观
ü 需求分析
Ø 发现问题背后的问题：深耕法
ü 需求定义
ü 需求确认
ü 需求规格
ü 需求变更控制
3、 阐述《软件客户需求权利书&软件客户需求义务书》的内容，建议以签约的形式完成。
ü 客户有如下权利：
Ø 要求分析人员使用符合客户语言习惯的表达。
Ø 要求分析人员了解客户系统的业务及目标。
Ø 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。
Ø 要求开发人员对需求过程中所产生的工作结果进行解释说明。
Ø 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。
Ø 要求开发人员对系统的实现及需求都要提供建议，拿出主意。
Ø 描述产品使其具有易用、好用的特性。
Ø 可以调整需求，允许重用已有的软件组件。
Ø 当需要对需求进行变更时，对成本、影响、得失（ t r a d e - o ff）有个真实可信的评估。
Ø 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。
ü 客户有下列义务：
Ø 给分析人员讲解业务及说明业务方面的术语等专业问题。
Ø 抽出时间清楚地说明需求并不断完善。
Ø 当说明系统需求时，力求准确详细。
Ø 需要时要及时对需求做出决策。
Ø 要尊重开发人员的成本估算和对需求的可行性分析。
Ø 对单项需求、系统特性或使用实例划分优先级。
Ø 评审需求文档和原型。
Ø 一旦知道要对项目需求进行变更，要马上与开发人员联系。
Ø 在要求需求变更时，应遵照开发组织确定的工作过程来处理。
Ø 尊重需求工程中开发人员采用的流程（过程）。
4、 明确需求过程中可能涉及的场地和沟通方式等问题
5. 会议特点
1、 正式的会议：一般有项目甲乙双方的高层、甲方核心业务人员和乙方项目经理需求人员等；
2、 参加的人员多：一般要求涉众人员都要参加；
3、 可以是正式会议的议题之一。也可以单独进行。
6. 会议目标
1、 达成对需求重要性的一致理解；
2、 了解甲乙双方在软件需求过程中各自拥有的权利和应尽义务；
3、 促进甲乙双方的涉众人员相互了解、认识；
4、 确定主要的沟通方式；
7. 会议成果
1、 签定了《软件客户需求权利书&软件客户需求义务书》；
浙公网安备 33010602011771号