课件：需求分析方法.pptx

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