需求分析规范.doc

EBS开发小组EBS需求分析规范-V1.0文档编号：文档名称：需求分析规范文档类别：分析和设计规范密 级：机密版本信息：1.0建立日期：2005-8-31创 建 人：D0001审 核 者：批 准 人：批准日期：编辑软件：Microsoft Office 2000 中文版文档修订记录版本编号*变化状态简要说明(变更内容和变更范围)日期变更人批准日期批准人更改请求号V1.0C2005-8-31D0001*变化状态：C创建,M修改，D删除文档审批信息序号审批人角色审批日期签字备注目录1简介41.1文档目的41.2适用范围42需求开发定义42.1什么是需求开发42.2各个步骤工作43需求开发策略43.1需求获取43.2需求分析63.3需求评审71 简介1.1 文档目的本文档中的内容是为了总结在需求分析方面的经验，制订相关的规范，指导分析人员完成需求分析工作。1.2 适用范围本文档的适用范围为软件项目开发中的分析和设计阶段。2 需求开发定义2.1 什么是需求开发需求开发是指软件工程中的需求阶段的分析研究等工作，需求开发又分为需求获取、需求分析、需求评审等三个步骤。软件的需求主要分为业务需求、用户需求和功能需求。业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求。用户需求文档描述了用户使用产品必须要完成的任务。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。2.2 各个步骤工作需求获取是需求开发中的与客户或行业专家交流探讨的过程，需求获取阶段主要目标是了解用户的目的目标，得到用户的业务需求和用户需求，估计开发风险，根据客户情况确定需求的优先级别。需求分析是需求开发中对需求获取得到的信息分析处理，建立用户需求模型，建立关联图，分析系统功能，得到功能需求，并完成需求用例、数据字典等文档，进行应用质量功能调配。需求评审是对需求开发阶段的评审，通常有客户或行业专家参加。主要是评审需求开发过程中的各种文档，制订总体的工作计划（包括设计开发计划、测试计划、实施计划等等），预算开发成本，签订正式开发意向等工作。3 需求开发策略3.1 需求获取l 先导入管理思想，再梳理业务流程。 百闻不如一见，百见不如一尝。没有亲历过信息化建设的人，对信息化的理解总是比较肤浅，甚至包括一些管理层成员。如上ERP系统时，如果一开始就让业务部门谈需求，业务人员谈得通常是当前工作中的困难或者希望实现的功能等。必须从转变观念入手，先给业务部门导入信息系统所包含的管理思想，然后协助业务部门梳理业务流程。l 表达要符合业务部门语言习惯 需求讨论集中于业务需求和任务，必然使用各种业务术语。应将有关业务术语教给需求获取或者分析人员，同时还要把常用的一些开发术语翻译给业务人员，做到交流畅通无阻。l 了解业务部门的业务及目标 只有充分了解业务部门的具体业务，才能开发出满足其需求的软件。为充分了解业务人员的具体需求，需求获取人员到业务部门去观察他们的实际工作流程，甚至与业务部门一起工作一段时间。如果是旧系统切换到新系统，还要亲自用一下目前的旧系统，明白目前系统是怎样工作的，了解其流程情况以及可供改进之处等。l 了解业务的特点以及我们普遍认识的误区或盲区充分了解业务的特点，了解用户需求的软件产品中的重要特性，比如：crm软件在软件和医疗设备等行业中重视的是售前管理和对业务人员的考核；在商贸行业或批发行业重视的是售中售后管理和对客户供应商的考核。从行业的特点出发，仔细分析用户的需求，不能自以为是，根据自己的认识想象或者揣摩用户的需求，这就是所谓的误区或盲区。l 掌握各种沟通技巧 需求获取的过程实际上是个沟通的过程，要想方设法吸引业务人员说出其需求。有时候，尝试着问一些愚蠢的问题也有助于用户打开话匣子。如果直接要求业务人员写出业务是如何实现的，十有八九无法完成；但如果尝试着问一些实际的问题，例如：以我的理解，你们收到订单后，会.。业务人员立刻就会指出你的错误，并滔滔不绝的开始谈论业务，这一招就叫抛砖引玉。l 客户所持的假设解释清楚尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。Gause 和Weinberg（1989）提出使用“上下文无关问题”这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。l 掌握好项目的范围在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。当前的范围太小，以致不能提供一个令人满意的产品。需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。l 让自己成为用户最高效的需求获取发生在需求获取者是需求对象方面的专家或者对需求对象相当了解的情况。如果你不是行业专家，那么在需求获取的过程中，你必须使自己成为该行业的熟悉者。能从行业的角度思考或讨论问题，让自己成为用户，才能使你更有效的跟客户交流，才能使你找到正确的需求和解决方法。l 寻找最近的原型同一个行业的项目开发都有很明显的共性，客户需要的项目可能我们自己的单位也需要，可以请教本单位的相关人员，或者以自己单位为原型做需求获取，或者由本单位相关人员参与需求获取，同行之间的交流会更加方便。l 与客户研讨需求获取讨论会中如果参与者过多，就会减慢进度。人数大致控制在5到7人是最好的。这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。l 对项目风险进行预估，分析项目可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。总结开发该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。l 收集需求中的业务例子和数据或用户使用故事业务例子和数据可以使设计、开发和测试人员更好的理解判断需求含义和业务逻辑，帮助开发测试过程验证程序正确性。短小精悍并且有点幽默的用户使用故事可以使人对需求留下深刻的印象，了解需求的目标，也就是极限编程中的隐喻。3.2 需求分析 l 有效的使用需求用例多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把这种看法系统地阐述成用例（用例）的方法进行需求获取和建模。最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。l 摆正需求的位置需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。你可以使用假设“怎么做”来分类并改善你对用户需求的理解。在需求的分析过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。l 需求分析的粒度在具体的需求过程中，有大的用例（业务用例），也有小的用例。主要是由于用例的范围决定的。用例像是一个黑盒，它没有包括任何和实现有关或是内部的一些信息。它很容易就被用户（也包括开发者）所理解（简单的谓词短语）。如果用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的Actor和用例。就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰的了解为止。l 制订统一的数据字典创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发过程中使用统一的数据命名。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义、术语以及术语的解释。l 创建开发原型当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。l 为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。l 确定需求优先级绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。l 应用质量功能调配功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。它将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。l 在更高的层面上分析需求客户所描述的需求往往只是业务上的需要，需求分析人员不能只根据用户的描述平面的分析出系统需求，需求分析人员需要在众多的客户需求中分析客户目标，了解真正的业务需求，在更高的层次上找到正确的解决方案，满足客户的需求。l 注意实现结果的过程系统分析往往注意了问题实现的最终结果或技术，而忽略了实现结果的过程。如做一个CRM中的客户关怀功能，需求分析人员往往都考虑了实现发短信或邮件来实现客户关怀，却忽略了用户需要设置一定的逻辑或规则来实现客户关怀。“用规则来发短信”规则不能被遗漏。l 注意精度问题涉及到数量或金额等计算时，特别注意精度问题，对精度处理不理想往往是很多软件的通病，计算过程和数的存储都回导致结果不正确。3.3 需求评审l 客户参与需求评审客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“