需求分析工程

需求分析工程培训时间：2小时培训目标什么是需求分析工程需求工程的意义需求工程的组成开展的基本步骤通过对于需求工程常识的了解，更好、更快、更合理的完成需求分析工作需求开发的详细过程什么是需求分析工程需求分析工程的定义需求分析工程的层次划分优秀需求分析的特征需求分析工程中的常见问题需求分析工程的定义•需求分析要解决的问题：为客户和开发队伍建立沟通的桥梁和标准•IEEE软件标准词汇中的定义用户解决问题或达到目标所需的条件权能系统或系统部件满足合同、标准、规范或其他正式规定文档所需的条件或权能一种反映上面两种描述的条件或权能的文档说明需求分析工程定义的通俗理解需求是在说明软件做什么，而不是怎么做需求是指明必须实现什么的规格说明，它描述了系统的行为、特性或属性它是在开发过程中对于系统的约束它必须以文档方式物理存在它必须准确体现了用户和开发者达成的共识什么是需求分析工程需求分析工程的定义需求分析工程的层次划分优秀需求分析的特征需求分析工程中的常见问题需求分析的层次划分我们对于任何事物的认识都是由浅到深、由宏观到微观的，这一现象也存在在需求分析中，并引发了需求分析的三个层次业务需求说明用户需求功能需求反映客户对于软件产品高层次的目标要求也就是系统做什么为了完成特定功能，操作用户和软件的交互逻辑或方式说明开发人员开发的软件的表现形式和相关约束。其他。。。什么是需求分析工程需求分析工程的定义需求分析工程的层次划分优秀需求分析的特征需求分析工程中的常见问题优秀需求分析的特征每一项需求都必须将所有要实现的功能说明清楚。每一项需求都必须准确的描述其要开发的功能。在软件实现角度必须可行。（软件工程人员参与评估）每一项需求都是客户真正需要的必须为每一项需求划分优先等级，以指明在整个产品中所占的分量需求说明的所有读者都只能有一个明确统一的解释每一项需求都必须能够通过设计测试用例或其他方法验证说明完整性正确性可行性必要性优先性无二性可验证性什么是需求分析工程需求分析工程的定义需求分析工程的层次划分优秀需求分析的特征需求分析工程中的常见问题需求分析中常见问题实际产品与客户期望差距太大，返工需求不断增加返工产品不能被客户接受浪费时间和精力导致结果过于精简项目视图和范围不明确需求说明有二义用户分类不完整画蛇添足问题培训目标什么是需求分析工程需求工程的意义需求工程的组成开展的基本步骤通过对于需求工程常识的了解，更好、更快、更合理的完成需求分析工作需求开发的详细过程需求工程的意义“开发软件最为困难的部分就是准确说明开发什么。同时，这也是一旦做错，给最终系统伤害最大的部分。”对客户说明对开发•帮助客户对于自己的要求作出准确的描绘•先于软件实现，在客户眼前详细描绘客户将要得到的系统的完整系统。•帮助系统分析人员全面掌握客户对于系统的要求。•是系统分析进行数据流分析和建立数据库结构的基础。•是后期进行用户测试的基础文档。支持人员常用的伎俩：由于。。原因，建议您重装WindowsXP失败的项目开发培训目标什么是需求分析工程需求工程的意义需求工程的组成开展的基本步骤通过对于需求工程常识的了解，更好、更快、更合理的完成需求分析工作需求开发的详细过程需求工程的组成和开展的基本步骤需求工程的基本组成需求开发的基本步骤需求管理的基本步骤需求开发与需求管理的关系需求工程基本上是由需求开发和需求管理两大部分组成需求工程需求开发需求管理项目视图和范围用户需求获取详细分析文档编写需求评审需求基线定义提出变更变更评审变更实施建立项目视图和范围说明用户需求获取•建立项目视图：明确产品所涉及的功能•明确范围约定：明确界定各项功能的范围约定详细分析编写文档需求评审•确定产品所期望的用户类。•获取每个用户类的需求•分析源于客户的信息，区分业务需求、用户需求、功能需求•分析系统的基本静态结构和基本动态结构•商讨实施的优先等级•编写相关文档•各类用户代表、需求分析人员、软件开发人员就需求达成共识需求管理的基本步骤定义需求基线说明评审变更•需求基线来源于需求开发协商承诺实施变更•评审提出的需求变更，评估每项变更的可能影响，从而决定是否实施以及实施的优先等级•估计变更的影响，并在此基础上，协商新的承诺（约定）•以可控的方式将需求变更融入项目进程中，使当前的项目计划与需求保持一致。需求管理的定义：建立并维护在软件工程中同客户达成的契约需求开发与需求管理的基本关系需求基线需求开发需求变更市场管理需求开发需求管理市场客户管理项目环境客户培训目标什么是需求分析工程需求工程的意义需求工程的组成开展的基本步骤通过对于需求工程常识的了解，更好、更快、更合理的完成需求分析工作需求开发的详细过程需求开发的详细过程项目视图和项目范围的建立用户需求获取详细分析需求评审项目视图和项目范围的建立目标说明相关名词•从需求的第一个层次——业务需求的层面，为项目确定一个明确的目标，并指明项目所涉及的范围结束标志•视图：描述了产品所涉及的各个方面在一个完美的环境中所具有的最终功能。•项目范围：描述了产品应包括的部分和不应包括的部分。同时，也说明了产品的局限性。•编写完成项目和视图范围文档，并在客户、开发队伍两个方面达成共识。后续工作•构架设计•用户需求获取项目视图和范围文档的基本结构业务需求部分说明项目视图部分•说明产品给客户的最初利益。也就是你为什么要从事此项目的开发以及它给客户带来的利益。具体包括业务机遇、业务目标、产品价值以及开发该产品的有关风险。项目范围部分•为产品建立一个长期的规划视图，从而进一步指明业务目标。具体包括项目视图说明、产品的主要特征说明。•澄清项目范围和产品使用的局限性。包括前面说明成立的假设和依赖环境。此部分可以依据项目建设周期，分阶段说明。成功因素部分•明确定义产品的成功是如何测量的。如果可能，应建立测量标准，用于评价是否达到业务目标。需求开发的详细过程项目视图和项目范围的建立用户需求获取详细分析需求评审用户需求获取目标说明最大的误区•搜集用户的需求，为下一步对需求分析的第二个层次—用户需求进行挖掘和详细分析打基础。其核心目标是致力于从各类用户手中完整、有效的搜集用户对于系统的期望和要求。结束标志•用户知道需求是什么•用户就是操作人•形成需求清单，并与客户和整个项目组达成共识。后续工作•进一步系统设计•用户需求分析实地观察访谈特定群体调查问卷调查用户指导原型制作统计分析用户需求的获取方法用户需求清单的基本规格用户需求清单是在问题获取阶段产生的，但其应用将贯穿项目的整个周期。用户类别用户需求名称描述状态优先等级实现时间要求实现成本需求开发的详细过程详细分析—基本结构—应注意的问题—关于用例分析方法的说明—需求文档的编写—需求分析工具及其工件编写模板详细分析－基本结构项目视图和范围文档用例分析文档1用例分析文档2规则文档项目字典页面功能设计文档1页面功能设计文档2详细分析—基本结构目标说明两种做法•以前两个阶段产生的项目视图和范围文档和客户需求清单为基础素材，对于用户需求和功能需求进行详细的分析和清理。结束标志•直接完成全部的用户需求分析和功能需求分析（包括最终页面的设计）。•只完成用户需求分析，功能需求分析和最终页面的实现由页面设计人员完成。•编写完成需求分析文档后续工作•需求评审需求开发的详细过程详细分析—基本结构—应注意的问题—关于用例分析方法的说明—需求文档的编写—需求分析工具及其工件编写模板详细分析—应该注意的问题层次问题说明词汇问题•从宏观到微观，从结构到规则，采用层层深入的方式分析。角度问题在需求分析中，应注意归纳和总结专业词汇，避免在不同的地方造成歧异。•各层面的分析都应该包括静态结构分析和动态结构分析两个部分。表现方式•可以用图形化表现的地方，尽量用图形化的说明方式沟通。沟通顺序•即使问题分析包括了功能需求部分，也应该在用户需求分析完成，并与客户和系统分析人员沟通确认后，再进行功能需求分析，并详细设计用户界面。需求开发的详细过程详细分析—基本结构—应注意的问题—关于用例分析方法的说明—需求文档的编写—需求分析工具及其工件编写模板详细分析—关于用例分析方法的说明用例定义说明•系统为了向其参与者提供有价值的结果而执行的动作序列。参与者指使用系统的一种用户。所有的系统参与者和所有的用例组合在一起，自然就形成了系统的模型方法的优点•帮助在需求分析阶段准确把握需求分析的视角•从使用者的视角描述系统功能，便于与客户沟通•帮助判定需求是否正确。•表达符号符合国际标准•它可以驱动整个开发过程。投保单录入员投保单预收录入详细分析—用例分析在详细分析阶段的应用在详细分析阶段，我们主要应用用例分析的基本思想和相关表现方式，说明分析对象的静态结构和动态结构通过用例图，分析和表现系统的静态结构通过活动图、状态图或者交互图，分析和表现系统的动态结构通过BusinessRules文档描述业务规则通过用例图，分析系统静态结构的基本步骤识别系统周围的参与者（系统的外部参与事物）对参与者进行归并，将类似的参与者泛化，并形成一个层次结构对于每个参与者，考虑他们期望的行为或者需要系统提供的行为，并为每个行为进行用例命名分解异常行为，形成新的用例，以使主要的控制流变的更加清晰。拆解用例中的公共行为，形成新的用例，供其他用例使用。在用例图中表现参与者与用例及其关系添加其他注释通过活动图、交互图、状态图，表现系统的动态结构活动图说明状态图•表现从活动到活动的控制流，本质上是一个流程图。当对象在控制点上从一个活动到另一个活动移动时，用活动图可以对该对象进行分析和说明。交互图•显示从状态到状态的控制流，本质上是一个流程图。当对象在控制点上从一个状态到另一个状态移动时，用状态图可以对该对象建模。•其目标是显示一个交互，它是由一组对象和他们之间的关系组成。其中，包括对象之间传递的消息。•交互图的表现形式：顺序图（强调消息的时间顺序）、协作图（强调发送和接收消息的对象之间的组织结构）通过BusinessRules文档描述业务规则广义含义：整个业务需求都可以称为BusinessRules狭义含义：系统在响应Actor的要求完成任务时做必须遵从的业务规则。BusinessRules本身也可以形成独立与用例的树状结构。Rules定义说明方法的优点•从方法角度：与用例内部对于系统职责的“黑盒”观点进行互补。•从需求维护角度：大量规则是跨用例的，而且规则的易变性高于用例，为了保证需求高效、一致的维护客户需求，BusinessRules需要与用例分离。需求开发的详细过程详细分析—基本结构—应注意的问题—关于用例分析方法的说明—需求文档的编写—需求分析工具及其工件编写模板需求分析文档的编写目的说明意义•需求分析文档作为客户和开发小组对于将要开发的产品达成的最终协议，综合体现了业务需求、用户需求和功能需求三个层次。•它作为协议的一部分，开发小组和客户都不能在它的基础上做任何假设。任何未体现在需求分析文档中的功能都不会体现在产品中。•客户依赖它来了解和评价开发小组将要开发的产品•项目管理人员根据它制定规划并预测进度。•软件开发小组依赖它来理解他们所要开发的产品•测试小组依赖它制定测试计划、测试用例和测试过程•软件维护和支持人员依赖它来了解产品的功能。•产品发布人员依赖它和界面设计文档来编写客户使用手册•培训人员依赖它和客户手册来编写培训教材。详细分析—基本结构—应注意的问题—关于用例分析方法的说明—需求文档的编写—需求分析工具及其工件编写模板需求开发的详细过程需求分析工具及工件编写模板需求分析辅助工具－Requestpro工件编写模板•Features•UserCase•BusinessRules需求开发的详细过程项目视图和项目范围的建立用户需求获取详细分析需求评审—基本结构—应注意的问题—关于用例分析方法的说明—需求文档的编写需求评审目标说明做法•以需求分析文档为基础，与用户和系统分析人员达成一致意