([需求分析规范.docVIP

EBS需求分析规范-V1.0 文档编号： 文档名称：需求分析规范 文档类别：分析和设计规范 密 级：机密 版本信息：1.0 建立日期：2005-8-31 创 建 人：D0001 审 核 者： 批 准 人： 批准日期： 编辑软件：Microsoft Office 2000 中文版  文档修订记录 版本编号 *变化 状态 简要说明 (变更内容和变更范围) 日期 变更人 批准日期 批准人 更改请求号 V1.0 C 2005-8-31 D0001 *变化状态：C——创建,M——修改，D——删除 文档审批信息 序号 审批人 角色 审批日期 签字 备注 目录 1 简介 4 1.1 文档目的 4 1.2 适用范围 4 2 需求开发定义 4 2.1 什么是需求开发 4 2.2 各个步骤工作 4 3 需求开发策略 4 3.1 需求获取 4 3.2 需求分析 6 3.3 需求评审 7  简介 文档目的 本文档中的内容是为了总结在需求分析方面的经验，制订相关的规范，指导分析人员完成需求分析工作。 适用范围 本文档的适用范围为软件项目开发中的分析和设计阶段。 需求开发定义 什么是需求开发 需求开发是指软件工程中的需求阶段的分析研究等工作，需求开发又分为需求获取、需求分析、需求评审等三个步骤。 软件的需求主要分为业务需求、用户需求和功能需求。 业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求。 用户需求文档描述了用户使用产品必须要完成的任务。 功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 各个步骤工作 需求获取是需求开发中的与客户或行业专家交流探讨的过程，需求获取阶段主要目标是了解用户的目的目标，得到用户的业务需求和用户需求，估计开发风险，根据客户情况确定需求的优先级别。 需求分析是需求开发中对需求获取得到的信息分析处理，建立用户需求模型，建立关联图，分析系统功能，得到功能需求，并完成需求用例、数据字典等文档，进行应用质量功能调配。 需求评审是对需求开发阶段的评审，通常有客户或行业专家参加。主要是评审需求开发过程中的各种文档，制订总体的工作计划（包括设计开发计划、测试计划、实施计划等等），预算开发成本，签订正式开发意向等工作。 需求开发策略 需求获取 先导入管理思想，再梳理业务流程。 百闻不如一见，百见不如一尝。没有亲历过信息化建设的人，对信息化的理解总是比较肤浅，甚至包括一些管理层成员。如上ERP系统时，如果一开始就让业务部门谈需求，业务人员谈得通常是当前工作中的困难或者希望实现的功能等。必须从转变观念入手，先给业务部门导入信息系统所包含的管理思想，然后协助业务部门梳理业务流程。 表达要符合业务部门语言习惯 需求讨论集中于业务需求和任务，必然使用各种业务术语。应将有关业务术语教给需求获取或者分析人员，同时还要把常用的一些开发术语翻译给业务人员，做到交流畅通无阻。 了解业务部门的业务及目标 只有充分了解业务部门的具体业务，才能开发出满足其需求的软件。为充分了解业务人员的具体需求，需求获取人员到业务部门去观察他们的实际工作流程，甚至与业务部门一起工作一段时间。如果是旧系统切换到新系统，还要亲自用一下目前的旧系统，明白目前系统是怎样工作的，了解其流程情况以及可供改进之处等。 了解业务的特点以及我们普遍认识的误区或盲区 充分了解业务的特点，了解用户需求的软件产品中的重要特性，比如：crm软件在软件和医疗设备等行业中重视的是售前管理和对业务人员的考核；在商贸行业或批发行业重视的是售中售后管理和对客户供应商的考核。从行业的特点出发，仔细分析用户的需求，不能自以为是，根据自己的认识想象或者揣摩用户的需求，这就是所谓的误区或盲区。 掌握各种沟通技巧 需求获取的过程实际上是个沟通的过程，要想方设法吸引业务人员说出其需求。有时候，尝试着问一些愚蠢的问题也有助于用户打开话匣子。如果直接要求业务人员写出业务是如何实现的，十有八九无法完成；但如果尝试着问一些实际的问题，例如：以我的理解，你们收到订单后，会...。业务人员立刻就会指出你的错误，并滔滔不绝的开始谈论业务，这一招就叫抛砖引玉。 客户所持的假设解释清楚 尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。Gause 和Weinberg（1989）提出使用