产品详细需求开发.docVIP

产品详细需求开发 制作： 审核： 批准： 发布日期： 欧索软件有限公司 OCEANSOFT INFORMATION SYSTEM CO., LTD 修订历史记录 日期 版本 说明 作者 2009年4月01日 讨论版本 李子刚 2009年4月10日 EPG修订 EPG 产品详细需求开发 目的 规范公司产品需求获取及分析的过程，提供一条可复制的相对成熟的需求挖掘、需求分析方法，提高需求阶段产出的质量。 为公司产品开发、升级奠定基础。 名词解释 项目：在本文中特指整个产品开发过程中阶段性工作的别名。 专家：公司中对某个业务或某种技术有较长工作经验和较多积累的人员。 角色流程图 启动准则 项目已经立项，需求工程师已进入项目组。 项目经理已细化项目计划中需求分析计划部分，并经过审批。 输入 《产品市场分析报告》 《可行性分析报告》 《销售策略报告》 《产品策划说明书》 主要活动 [Activity1]：详细需求调研准备 Step1确定调研客户 调研客户一般来自于产品策划中调研过的客户对象，由产品部门和销售部门一起确定具有典型意义的客户。 调研对象可以是一个或多个。 如果存在多个调研对象，则需要分别完成下述的步骤。 Step2 确定调研计划 制定与客户相关的调研计划，并完成和客户的确认。 相关活动需要销售部门的协助。 Step3 准备调研材料 从产品策划中得到产品有关的模块列表、报表列表、表单列表等。 从产品策划中得到产品的产品策划书。 从产品策划中得到相关客户分析资料。 从产品策划中得到《调研准备分析报告》，稍作调整和修改以作为本次调研的依据。 [Activity2]：调研并记录 需求工程师根据《调研准备分析报告》和调研计划进行需求调研工作，并将调研过程中所获取的需求信息记录到《用户需求调研单》中。 如果信息或者资料比较多，可以另起文件进行说明，然后作为《用户需求调研单》的附件进行存储。 在调研过程中，相关提问方式和收集资料的渠道请参考《需求开发指导书》。 [Activity3]：分析并细化 需求工程师分析调研成果，概述分为以下几步： 第一阶段：定义业务流程，产生业务用例模型； 第二阶段：分析业务流程，产生具体业务活动模型； 第三阶段：定义系统范围，产生系统用例图； 意外流程：对于需求分析中不确定问题，需求工程师及时记录并重新调研与记录。 详细的请参考《需求分析指导书》。 [Activity4]：编写详细需求文档 需求工程师分析系统流程，产生业务用例叙述。 完成详细需求文档的编写。 产品详细需求文档主要是生成两种文件，一种是分析设计使用的EA文件，另一种是使用EA生成的HTML文件，这两个文件都应在生成和变更后及时的放入产品配置库中，以供项目其它成员阅读和参考。 产品详细需求EA文件 产品详细需求HTML文件 [Activity5]：开发产品原型 产品的界面布局设计\界面色调设计\界面操作风格设计由产品经理主导，公司美工负责整体设计。具体方法请参考“产品原型设计”规程。 UI工程师熟悉原型设计规范、总体UI规格，并按照这个思路进行详细原型的开发。 UI工程师根据需求调研成果，与需求工程师讨论并开发需求的UI视图，从侧面协助需求工程师更深入的挖掘潜在需求。 [Activity6]：需求走查 需求工程师按计划提交详细需求文档，UI工程师按计划提交原型成果。 产品经理组织人员按计划对提交的成果是否满足要求（文档的完整性，规范性，业务合理性等）进行走查评审，走查评审的过程及规定请参见同级评审过程域中的走查规程。 一般按照各个功能模块进行走查。 [Activity7]：需求审查 在产品的详细需求和DEMO完成后，由需求工程师完成文档整合。 业务总监召集相关领域的专家（技术类：检验可行性；业务性：检验合理性）对提交的成果做评审，评审过程采用同级评审中的审查规程。关于同级评审的规定请参见同级评审过程域中的审查规程。 业务总监对评审通过的成果填写评审会议记录。产品经理保留此份签字。 评审记录归档。 输出 《用户需求调研单》 《产品详细需求EA文件》 《产品详细需求HTML文件》 《产品原型》 《评审会议记录》 结束准则 评审会议通过产品详细需求文档，《产品原型》的评审 《需求跟踪报告》中的需求跟踪矩阵“需求”部分已初始化 产品UI规格设计 目的 为产品开发制订符合产品线要求的总体框架、详细的UI规格以及产品发布的VI设计样式，指导详细的原型开发工作和实际产品界面开发工作以及产品发布工作。 规范公司产品UI规格分析的过程，提供一条可复制的相对成熟的创建原型以及优化的方法，提高客户的使用舒适度。 产品部的执行总监总体负责产品UI规格设计过程。 名词解释 项目：在本文中特指整个产品开发过程中阶段性工作的别名。 专家：公司中对某个业务或某种技术有