需求分析管理工程.ppt

1、需求分析工程培训,时间：2小时,培训目标,什么是需求分析工程,需求工程的意义,需求工程的组成开展的基本步骤,通过对于需求工程常识的了解，更好、更快、更合理的完成需求分析工作,需求开发的详细过程,什么是需求分析工程,需求分析工程的定义,需求分析工程的层次划分,优秀需求分析的特征,需求分析工程中的常见问题,需求分析工程的定义,需求分析要解决的问题： 为客户和开发队伍建立沟通的桥梁和标准,IEEE软件标准词汇中的定义 用户解决问题或达到目标所需的条件权能 系统或系统部件满足合同、标准、规范或其他正式规定文档所需的条件或权能 一种反映上面两种描述的条件或权能的文档说明,需求分析工程定义的通俗理解,需求

2、是在说明软件做什么，而不是怎么做,需求是指明必须实现什么的规格说明，它描述了系统的行为、特性或属性,它是在开发过程中对于系统的约束,它必须以文档方式物理存在,它必须准确体现了用户和开发者达成的共识,什么是需求分析工程,需求分析工程的定义,需求分析工程的层次划分,优秀需求分析的特征,需求分析工程中的常见问题,需求分析的层次划分,我们对于任何事物的认识都是由浅到深、由宏观到微观的，这一现象也存在在需求分析中，并引发了需求分析的三个层次,业务需求,说 明,用户需求,功能需求,反映客户对于软件产品高层次的目标要求也就是系统做什么,为了完成特定功能，操作用户和软件的交互逻辑或方式,说明开发人员开发的软件

3、的表现形式和相关约束。,其他。,什么是需求分析工程,需求分析工程的定义,需求分析工程的层次划分,优秀需求分析的特征,需求分析工程中的常见问题,优秀需求分析的特征,每一项需求都必须将所有要实现的功能说明清楚。,每一项需求都必须准确的描述其要开发的功能。,在软件实现角度必须可行。（软件工程人员参与评估）,每一项需求都是客户真正需要的,必须为每一项需求划分优先等级，以指明在整个产品中所占的分量,需求说明的所有读者都只能有一个明确统一的解释,每一项需求都必须能够通过设计测试用例或其他方法验证,说 明,完整性,正确性,可行性,必要性,优先性,无二性,可验证性,什么是需求分析工程,需求分析工程的定义,需求

4、分析工程的层次划分,优秀需求分析的特征,需求分析工程中的常见问题,需求分析中常见问题,实际产品与客户期望差距太大，返工,需求不断增加,返工,产品不能被客户接受,浪费时间和精力,导致结果,过于精简,项目视图和范围不明确,需求说明有二义,用户分类不完整,画蛇添足,问题,培训目标,什么是需求分析工程,需求工程的意义,需求工程的组成开展的基本步骤,通过对于需求工程常识的了解，更好、更快、更合理的完成需求分析工作,需求开发的详细过程,需求工程的意义,“开发软件最为困难的部分就是准确说明开发什么。同时，这也是一旦做错，给最终系统伤害最大的部分。”,对客户,说 明,对开发,帮助客户对于自己的要求作出准确的描

5、绘 先于软件实现，在客户眼前详细描绘客户将要得到的系统的完整系统。,帮助系统分析人员全面掌握客户对于系统的要求。 是系统分析进行数据流分析和建立数据库结构的基础。 是后期进行用户测试的基础文档。,支持人员常用的伎俩：由于。原因，建议您重装Windows XP,失败的项目开发,培训目标,什么是需求分析工程,需求工程的意义,需求工程的组成开展的基本步骤,通过对于需求工程常识的了解，更好、更快、更合理的完成需求分析工作,需求开发的详细过程,需求工程的组成和开展的基本步骤,需求工程的基本组成,需求开发的基本步骤,需求管理的基本步骤,需求开发与需求管理的关系,需求工程基本上是由需求开发和需求管理两大部分

6、组成,需求 工程,需求开发,需求管理,项目视图和范围,用户需求获取,详细分析,文档编写,需求评审,需求基线定义,提出变更,变更评审,变更实施,建立项目 视图和范围,说 明,用户需求获取,建立项目视图：明确产品所涉及的功能 明确范围约定：明确界定各项功能的范围约定,详细分析,编写文档,需求评审,确定产品所期望的用户类。 获取每个用户类的需求,分析源于客户的信息，区分业务需求、用户需求、功能需求 分析系统的基本静态结构和基本动态结构 商讨实施的优先等级,编写相关文档,各类用户代表、需求分析人员、软件开发人员就需求达成共识,需求管理的基本步骤,定义需求基线,说 明,评审变更,需求基线来源于需求开发,

7、协商承诺,实施变更,评审提出的需求变更，评估每项变更的可能影响，从而决定是否实施以及实施的优先等级,估计变更的影响，并在此基础上，协商新的承诺（约定）,以可控的方式将需求变更融入项目进程中，使当前的项目计划与需求保持一致。,需求管理的定义：建立并维护在软件工程中同客户达成的契约,需求开发与需求管理的基本关系,需求基线,需求 开发,需求 变更,市 场,管理,需求开发,需求管理,市场客户管理,项目环境,客户,培训目标,什么是需求分析工程,需求工程的意义,需求工程的组成开展的基本步骤,通过对于需求工程常识的了解，更好、更快、更合理的完成需求分析工作,需求开发的详细过程,需求开发的详细过程,项目视图和

8、项目范围的建立,用户需求获取,详细分析,需求评审,项目视图和项目范围的建立,目标,说 明,相关名词,从需求的第一个层次业务需求的层面，为项目确定一个明确的目标，并指明项目所涉及的范围,结束标志,视图：描述了产品所涉及的各个方面在一个完美的环境中所具有的最终功能。 项目范围：描述了产品应包括的部分和不应包括的部分。同时，也说明了产品的局限性。,编写完成项目和视图范围文档，并在客户、开发队伍两个方面达成共识。,后续工作,构架设计 用户需求获取,项目视图和范围文档的基本结构,业务需求部分,说 明,项目视图部分,说明产品给客户的最初利益。也就是你为什么要从事此项目的开发以及它给客户带来的利益。具体包括

9、业务机遇、业务目标、产品价值以及开发该产品的有关风险。,项目范围部分,为产品建立一个长期的规划视图，从而进一步指明业务目标。具体包括项目视图说明、产品的主要特征说明。,澄清项目范围和产品使用的局限性。包括前面说明成立的假设和依赖环境。此部分可以依据项目建设周期，分阶段说明。,成功因素部分,明确定义产品的成功是如何测量的。如果可能，应建立测量标准，用于评价是否达到业务目标。,需求开发的详细过程,项目视图和项目范围的建立,用户需求获取,详细分析,需求评审,用户需求获取,目标,说 明,最大的误区,搜集用户的需求，为下一步对需求分析的第二个层次用户需求进行挖掘和详细分析打基础。其核心目标是致力于从各类

10、用户手中完整、有效的搜集用户对于系统的期望和要求。,结束标志,用户知道需求是什么 用户就是操作人,形成需求清单，并与客户和整个项目组达成共识。,后续工作,进一步系统设计 用户需求分析,实地观察 访谈 特定群体调查 问卷调查 用户指导 原型制作 统计分析,用户需求的获取方法,用户需求清单的基本规格,用户需求清单是在问题获取阶段产生的，但其应用将贯穿项目的整个周期。,需求开发的详细过程,详细分析, 基本结构 应注意的问题 关于用例分析方法的说明 需求文档的编写 需求分析工具及其工件编写模板,详细分析基本结构,项目视图和范围文档,用例 分析 文档1,用例 分析 文档2,规则 文档,项目 字典,页面功

11、能 设计文档1,页面功能 设计文档2,详细分析 基本结构,目标,说 明,两种做法,以前两个阶段产生的项目视图和范围文档和客户需求清单为基础素材，对于用户需求和功能需求进行详细的分析和清理。,结束标志,直接完成全部的用户需求分析和功能需求分析（包括最终页面的设计）。 只完成用户需求分析，功能需求分析和最终页面的实现由页面设计人员完成。,编写完成需求分析文档,后续工作,需求评审,需求开发的详细过程,详细分析, 基本结构 应注意的问题 关于用例分析方法的说明 需求文档的编写 需求分析工具及其工件编写模板,详细分析 应该注意的问题,层次问题,说 明,词汇问题,从宏观到微观，从结构到规则，采用层层深入的

12、方式分析。,角度问题,在需求分析中，应注意归纳和总结专业词汇，避免在不同的地方造成歧异。,各层面的分析都应该包括静态结构分析和动态结构分析两个部分。,表现方式,可以用图形化表现的地方，尽量用图形化的说明方式沟通。,沟通顺序,即使问题分析包括了功能需求部分，也应该在用户需求分析完成，并与客户和系统分析人员沟通确认后，再进行功能需求分析，并详细设计用户界面。,需求开发的详细过程,详细分析, 基本结构 应注意的问题 关于用例分析方法的说明 需求文档的编写 需求分析工具及其工件编写模板,详细分析 关于用例分析方法的说明,用例定义,说 明,系统为了向其参与者提供有价值的结果而执行的动作序列。参与者指使用

13、系统的一种用户。所有的系统参与者和所有的用例组合在一起，自然就形成了系统的模型,方法的优点,帮助在需求分析阶段准确把握需求分析的视角 从使用者的视角描述系统功能，便于与客户沟通 帮助判定需求是否正确。 表达符号符合国际标准 它可以驱动整个开发过程。,详细分析 用例分析在详细分析阶段的应用,在详细分析阶段，我们主要应用用例分析的基本思想和相关表现方式，说明分析对象的静态结构和动态结构,通过用例图，分析和表现系统的静态结构 通过活动图、状态图或者交互图，分析和表现系统的动态结构 通过Business Rules文档描述业务规则,通过用例图，分析系统静态结构的基本步骤,识别系统周围的参与者（系统的外

14、部参与事物） 对参与者进行归并，将类似的参与者泛化，并形成一个层次结构 对于每个参与者，考虑他们期望的行为或者需要系统提供的行为 ，并为每个行为进行用例命名 分解异常行为，形成新的用例，以使主要的控制流变的更加清晰。 拆解用例中的公共行为，形成新的用例，供其他用例使用。 在用例图中表现参与者与用例及其关系 添加其他注释,通过活动图、交互图、状态图，表现系统的动态结构,活动图,说 明,状态图,表现从活动到活动的控制流，本质上是一个流程图。当对象在控制点上从一个活动到另一个活动移动时，用活动图可以对该对象进行分析和说明。,交互图,显示从状态到状态的控制流，本质上是一个流程图。当对象在控制点上从一个

15、状态到另一个状态移动时，用状态图可以对该对象建模。,其目标是显示一个交互，它是由一组对象和他们之间的关系组成。其中，包括对象之间传递的消息。 交互图的表现形式：顺序图（强调消息的时间顺序）、协作图（强调发送和接收消息的对象之间的组织结构）,通过Business Rules文档描述业务规则,广义含义：整个业务需求都可以称为Business Rules 狭义含义：系统在响应Actor的要求完成任务时做必须遵从的业务规则。 Business Rules本身也可以形成独立与用例的树状结构。,Rules定义,说 明,方法的优点,从方法角度：与用例内部对于系统职责的“黑盒”观点进行互补。 从需求维护角度：

16、大量规则是跨用例的，而且规则的易变性高于用例，为了保证需求高效、一致的维护客户需求，Business Rules需要与用例分离。,需求开发的详细过程,详细分析, 基本结构 应注意的问题 关于用例分析方法的说明 需求文档的编写 需求分析工具及其工件编写模板,需求分析文档的编写,目的,说 明,意义,需求分析文档作为客户和开发小组对于将要开发的产品达成的最终协议，综合体现了业务需求、用户需求和功能需求三个层次 。 它作为协议的一部分，开发小组和客户都不能在它的基础上做任何假设。任何未体现在需求分析文档中的功能都不会体现在产品中。,客户依赖它来了解和评价开发小组将要开发的产品 项目管理人员根据它制定规划并预测进度。 软件开发小组依赖它来理解他们所要开发的产品 测试小组依赖它制定测试计划、测试用例和测试过程 软件维护和支持人员依赖它来了解产品的功能。 产品发布人员依赖它和界面设计文档来编写客户使用手册 培训人员依赖它和客户手册来编写培训教材。,详细分析, 基本结构 应注意的问题 关于用例分析方法的说明 需求文档的编写 需求分析工具及其工件编写