需求分析方法PPT课件.pptx

需 求 分 析 方 法1.1 1软软件需求的基件需求的基础础知知识识目录1.1 1.1 需求分析在需求分析在软软件开件开发发中所中所处处的位置的位置1.2 1.2 什么是什么是软软件需求件需求1.3 1.3 软软件需求的件需求的类类型型1.4 1.4 软软件需求的分件需求的分类类1.5 1.5 质质量属性的分量属性的分类类1.6 1.6 需求需求对对架构的影响架构的影响1.7 1.7 需求的易需求的易变变更性更性2.二二.需求分析需求分析实实践践目录2.1 2.1 需求的需求的获获取取2.2 2.2 需求分析的目的需求分析的目的2.3 2.3 需求分析的思需求分析的思维维方式方式2.4 2.4 软软件需求的分件需求的分层层2.5 2.5 需求分析的步需求分析的步骤骤2.6 2.6 好的需求有哪些特征好的需求有哪些特征2.7 2.7 需求需求验证验证与确与确认认3.三三.需求管理需求管理目录3.1 3.1 需求需求总总是是变变化的化的3.2 3.2 需求是需求是渐变渐变的的3.3 3.3 如何如何应对应对需求需求变变更更4.1软件需求的基础知识5.在一个以 软件架构件架构为中心中心 的软件项目开发过程中，需求分析在概念化阶段和架构设计之间。软件需求的基础知识概念化阶段分析阶段架构设计阶段详细设计阶段并行开发与测试阶段验收与交付阶段交付的系统软件需求规格软件架构文档软件设计文档代码及集成系统愿景文档1.1 1.1 需求分析在需求分析在软软件开件开发发中所中所处处的位置的位置6.“这这个个个个软软件到底要件到底要件到底要件到底要为为用用用用户户做什么？做什么？做什么？做什么？”软件需求的基础知识1.2 1.2 什么是什么是软软件需求件需求IEEE将需求定义为：1.用户所需的解决某个问题或达到某个目标索要具备的条件或能力。2.系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足条件或必须具备的能力。RUP（统一软件开发过程）将需求定义为：1.需求描述了系统必须满足的情况或提供的能力，它可以是直接来自客户需求，也可以来自合同、标准、规范或其他有正规约束力的文档。7.软件需求的基础知识软件需求1.3 1.3 软软件需求的件需求的类类型型非功能需求功能需求质质量属性量属性量属性量属性约束开发期质量属性运行期质量属性界面需求软件架构重点关注的是质量属性。架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性。商业需求8.软件需求的基础知识1.4 1.4 软软件需求的分件需求的分类类p功能需求功能需求 描述要开发的 软件系统应该做什么，既包括为用户提供的服务，又包括本系统为其他系统提供的服务。p非功能需求非功能需求 包括质量属性，界面需求，约束 以及 商业需求。质量属性是架构设计最受关注的需求。架构设计通常不涉及界面需求。约束需求规定了开发软件系统时必须遵守的限制条件。如：为了获得相关行业或组织的认可，或者大型企业集团处于长期整合规划的要求；软件的设计和开发可能还必须遵守相关行业标准、企业标准等约束。商业需求可能包含系统的上线时间要求，成本因素等。9.软件需求的基础知识1.5 1.5 质质量属性的分量属性的分类类p软件质量属性分为运行期质量属性和开发期质量属性两大类：开发期质量属性包含了和软件开发、维护和移植这三类活动相关的所有质量属性；开发期质量属性是开发人员、开发管理人员和维护人员都非常关心的，对最终用户而言，这些质量属性只是间接地促进用户需求的满足；运行期质量属性是软件系统在运行期间，最终用户可以直接感受到的一类属性，这些质量属性直接影响着用户对软件产品的满意度。10.软件需求的基础知识1.5 1.5 质质量属性的分量属性的分类类运行期质量属性开发期质量属性性能（Performance）安全性（Security）易用性（Usability）可用性（Availability）可伸缩性（Scalability）互操作性（Interoperability）可靠性（Reliability）鲁棒性（Robustness）易理解性（Understandability）可扩展性（Extensibility）可重用性（Reusability）可测试性（Testability）可维护性（Maintainability）可移植性（Portability）11.软件需求的基础知识1.5 1.5 质质量属性的分量属性的分类类p性能（Performance）：软件系统及时提供相应服务的能力，包括速度、吞吐量和持续行三个方面的要求吞吐量通过单位时间处理的交易数来度量速度往往通过平均响应时间来度量持续时间是指保持高速处理速度的能力p安全性（Security）：软件同时兼顾向合法用户提供服务，以及阻止非授权使用的能力p易用性（Usability）：软件易于使用的程度p持续可用性（Availability）：在预定的运行时间中，系统真正可用并且完全运行时间所占的百分比。12.软件需求的基础知识1.5 1.5 质质量属性的分量属性的分类类p可伸缩性（Scalability）：当用户数和数据量增加时，软件系统维持高服务质量的能力p互操作性（Interoperability）：本软件系统与其他软件系统交换数据和相互调用服务的难易程度p可靠性（Reliability）：软件在一定时间内无故障运行的能力p鲁棒性（Robustness）：软件系统在以下情况仍能够正常运行的能力：用户进行了非法操作；相连的软硬件系统发生了故障，以及其他非正常情况。13.软件需求的基础知识1.5 1.5 质质量属性的分量属性的分类类 提高可靠性需要强调减少系统中断（故障）的次数，提高可用性需要强调减少从灾难中恢复的时间。A系统每年因故障中断十次，每次恢复平均要20分钟，B系统每年因故障中断2次，每次需5小时恢复。则A系统可用性比B系统高，但可靠性比B系统差。可靠性的量化指标是周期内系统平均无故障运行时间，可用性的量化指标是周期内系统无故障运行的总时间。一般提高可靠性的同时，也同时提高了可用性。要提高可靠性，可使用变更管理，UPS，RAID，Cluster，链路冗余等管理和技术手段减少系统Down机的可能性。要提高可用性，除提高可靠性外，还可以使用合理备份，业务连续性计划等方式来减少从灾难中恢复的时间。14.软件需求的基础知识1.5 1.5 质质量属性的分量属性的分类类p易理解性（Understandability）：指设计被开发人员理解的难易程度p可扩展性（Extensibility）：为适应新需求或需求变化为软件增加功能的能力p可重用性（Reusability）：重用软件系统或者其中一部分的能力的难易程度p可测试性（Testability）：对软件测试以证明其满足需求规约的难易程度p可维护性（Maintainability）：对软件运行时进行维护的难易程度p可移植性（Portability）：将软件系统从一个环境转移到另一个环境的难易程度15.软件需求的基础知识1.6 1.6 需求需求对对架构的影响架构的影响功能需求架构质量属性约束导致某些功能需求导致某些质量属性需求支持限制影响适应更大的影响遵守关关键键需求决定架构，其他需求需求决定架构，其他需求验证验证架构。架构。16.软件需求的基础知识1.7 1.7 需求的易需求的易变变更性更性p需求的变更既蕴含了风险，又包含了机遇p需求变更可能有三类来源我们要解决的问题发生了变化我们对问题的理解发生了变化我们理解问题的过程有误17.软件需求的基础知识1.7 1.7 需求的易需求的易变变更性更性p功能需求最易变，而质量属性需求最稳定p功能需求的易变性中潜藏着两类不易变性功能需求中存在少量长期稳定的功能功能点本身趋于稳定p约束性需求的稳定性稍差，技术趋势发生变化、法律规范重新界定、用户组织调整，都有可能使约束性需求变更易变更性（从低到高）质量属性需求约束性需求功能需求18.二.需求分析实践19.软件需求分析实践2.1 2.1 需求的需求的获获取取p需求获取五步法1.收集资料，了解概况，初步划定范围2.识别所有可能的需求提供者3.准备需要了解调研的问题4.调查和访谈5.总结归纳，准备新的问题，多次迭代20.软件需求分析实践2.1 2.1 需求的需求的获获取取p需求获取的方式与用户个别交流需求讨论会查阅相关文档分发问卷调查表现场访问客户业务流程分析同类产品分析根据现有系统推导需求回顾以往项目观察用户对原有系统的使用21.软件需求分析实践2.1 2.1 需求的需求的获获取取p识别所有可能的需求提供者谁使用该系统谁维护该系统谁需要从系统中获取数据系统会影响到谁谁推广该系统谁测试该系统谁生产该系统谁购买该系统22.软件需求分析实践2.1 2.1 需求的需求的获获取取p需求获取的常用技术需求访谈推荐3人访谈小组（1人提问，1人记录，1人辅助）用例技术最终用户使用用例来模拟 用户与系统之间交互用例可以看作是解释如何使用系统的经历原型法需求原型；设计原型；产品原型纸上原型；界面原型；可执行原型抛弃型原型；演化型原型专题讨论会（头脑风暴）23.软件需求分析实践2.2 2.2 需求分析的目的需求分析的目的p消除原始需求中存在的：冲突重叠遗漏不一致不切实际的p细化需求p划分需求的优先级p需求建模24.软件需求分析实践2.3 2.3 需求分析的思需求分析的思维维方式方式p穷举：确保需求无遗漏p分类：确保需求无遗漏并去除冗余的需求p分层：结构化表达需求p抽象：识别出稳定与变化的需求25.软件需求分析实践2.4 2.4 需求的分需求的分层层提出者获取方法文档量文档形式评审方式稳定性返工影响优先级的确定者目标需求高层经理访谈几页ppt,word正规评审会最稳定最大客户业务需求中层经理访谈几十页excel,word正规评审会较稳定次之客户操作需求操作员+开发人员原型几十页,上百页word非正式评审会,正规评审会,分多次评审最易变化局部影响客户+开发人员26.软件需求分析实践2.5 2.5 需求分析的步需求分析的步骤骤p步骤一：列举需求1.消除客户需求中的矛盾与不一致2.补充遗漏的客户需求3.删除不必要的需求4.定义非功能性需求5.定义外部接口需求27.软件需求分析实践2.5 2.5 需求分析的步需求分析的步骤骤p步骤二：整理需求1.功能分解2.定义内部接口3.平衡需求、进度、质量与投入4.识别需求相关的风险5.对需求进行分类6.划分需求优先级7.识别可复用需求8.建立需求分析模型28.软件需求分析实践2.5 2.5 需求分析的步需求分析的步骤骤p步骤三：需求建模需求建模方法结构化建模IPOER图数据流程数据字典面向对象建模USE CASE 模型USE CASE 图USE CASE 描述静态建模类图包图动态建模交互图简单的理解为将自然语言描述的需求转换为开发人员能够理解的设计语言。29.软件需求分析实践2.5 2.5 需求分析的步需求分析的步骤骤p步骤四：设定系统目标与划分系统范围 目标 要解决的核心问题是什么?为解决该问题的约束有哪些?范围 哪些是系统应该完成的任务?哪些不是系统的责任?从广度与深度2个纬度考虑范围 广度：覆盖的业务,部门,功能 深度：做到什么程度？Gilb的模糊目标定律：一个没有明确目标的项目，是不可能明确地实现其目标的。30.软件需求分析实践2.5 2.5 需求分析的步需求分析的步骤骤p步骤五：划分需求的优先级1.优先级的分配由系统分析员和客户一起完成2.优先级一般分为3级，不宜定义太多的等级3.帮助客户定义优先级的问题：最重要的3个需求是什么？是否有其他方法可以满足这一需求？如果忽略或者推迟实现这一需求，其后果是什么？如果不立即实现这一需求，对项目目标会有什么影响？4.需求的优先级可以从两个层次来划分用户划分宏观的优先级：需求优先级开发划分微观的优先级：特性优先级5.需求的优先级影响了开发顺序和开发计划 31.软件需求分析实践2.5 2.5 需求分析的步需求分析的步骤骤p步骤六：使用需求分析检查单来分析需求1.检查单中的问题：需求中包含不成熟的设计或实现信息吗？这项需求还可以细分为不同的需求吗？这项需求只是系统的装饰，而不是真正必须的吗？这项需求符合系统的目标吗？这项需求存在二义性吗？这项需求可以实现吗？这项需求是可测试的吗？32.软件需求分析实践2.6 2.6 好的需求有哪些特征好的需求有哪些特征正确清楚无二义性一致必要完备可实现可验证确定优先级阐述“做什么”，而不是“怎么做”33.软件需求分析实践2.7 2.7 需求需求规规格格说说明明书书ReleaseProduct BacklogSprint4 weekSprint BacklogDaily meetingsBurn downScrum开发模型34.软件需求分析实践2.8 2.8 需求需求验证验证与确与确认认方式方式检查文档是否符合标准组织正式的需求审查需求审查应有一个多学科的小组来进行使用原型来确认需求编写用户手册草案设计测试用例检查文档是否符合标准组织正式的需求审查需求审查应有一个多学科的小组来进行使用原型来确认需求编写用户手册草案设计测试用例检查文档是否符合标准组织正式的需求审查需求审查应有一个多学科的小组来进行使用原型来确认需求编写用户手册草案设计测试用例检查文档是否符合标准组织正式的需求审查需求审查应有一个多学科的小组来进行使用原型来确认需求编写用户手册草案设计测试用例35.二.需求管理36.软件需求管理3.1 3.1 需求的需求的变变化是永恒的化是永恒的p需求变化的原因1.误解2.遗漏了需求3.外部环境发生了变化，产生了新的需求37.软件需求管理3.2 3.2 需求是需求是渐变渐变的的秃头论证稻草原理蚂蚁效应量量变变引起引起质变质变。当你警。当你警觉时觉时，项项目已目已经变经变得面目全非了。得面目全非了。38.软件需求管理3.3 3.3 如何如何应对应对需求需求变变更更商务手段沟通手段技术手段管理手段ReleaseProduct BacklogSprint4 weekSprint BacklogDaily meetingsBurn down39.参考参考资料料 软件需求 机械工业出版社 Karl E.Wiegers著,陆丽娜等翻译 2000年.探索需求 清华大学出版社 Weinberg等著,章柏幸等翻译 2004年 需求工程 机械工业出版社 Ian Sommerville等著,赵文耘等翻译 2003年 软件需求管理统一方法 机械工业出版社 DeanLeffingwell Don Widrig 著,蒋慧 林东译 2002年40.Thank you!41.