软件需求工程第一部分需求工程综述(精)PPT课件

2020/5/22，1，1，软件需求工程软件requirements(sre )第一部分需求工程概要第三章需求工程推荐方法，王如龙，2/16，第一章回顾，定义一个2部分3个层次4个文件，软件需求是顾客需求信息和软件行为、特性、设计和开发约束的记述集合。 需求工序=需求开发需求管理、业务需求、用户需求功能和非功能需求、愿景和范围用例SRS模型、3/16、第二章复查、客户和用户权利和义务合同的意义、客户：具体阐明产品的上位概念和主要业务内容，决定支付的决策者。 用户：明确说明软件功能和非功能性需求和特性，最终能够使用系统的人。 在明确客户权利的同时，在行使开发人员权利的同时，认真履行开发人员义务，是开发人员应尽的职业培训，帮助客户认识到自己应尽的义务是保证项目成功的基本保证。 合同表明了签约人合作开发产品的需求分析过程和过程结果的确认。 合同生效后，至少(1)表明需求开发阶段结束的(2)之后的需求变更在该基线上进行。 4/16、学习目标、学习本章内容后，应该能理解开发软件需求的主要方法。 了解软件需求管理的主要方法。 掌握方法的特点、差异和使用方法。 5/16、需求工程方法(2部7大班46方法)、知识技能(4)需求分析者培训用户和管理员培训开发人员的应用领域培训组件术语(11 )需求开发过程定义项目的前景和范围决定用户组选择用户的代表者建立核心团队， 实施用例决策系统事件和响应进一步获得需求的讨论，观察用户如何检查问题报告的需求重用，建立分析(8)关联图确定原型分析的可行性，确定需求优先级，建立需求模型，建立数据字典， 将需求应用于每个字体系统的质量功能计划(3)审核需求文档的测试需求以确定合格标准，并创建SRS (5)使用SRS模板定义需求来源记录在每个需求附注中的业务规范的质量属性，然后进行项目管理(6) 选择适当的开发周期，根据需求计划重新协商权利和义务管理需求风险，追踪需求的工作回顾过去的教训需求管理(9)定义变更管理流程变更管理委员会分析需求变更的影响，管理需求版本， 使用跟踪基线维护变更历史记录来测定需求稳定性的需求管理工具制作需求跟踪矩阵，需求开发方法(4大类27个)，需求管理方法(3大类19个)，图3-1需求施工方法的结构图，p28， 6/16 3.1获得知识技能的方法是需求分析师训练用户代表和管理员并训练开发人员的应用领域训练组件术语，成为分析师的所有团队成员必须经过需求过程的基本训练。 需求分析专家为了明确必要的基本条件和掌握的技能，必须实施一周以上的训练。 对参与软件需求开发的客户、用户和开发管理员进行从1天到2天左右的需求工序培训，了解需求的重要性，忽略需求带来的风险。 组织对客户业务流程、组织活动、工作目标、业务术语等的简短学习和培训，使开发人员基本了解软件应用领域，增加对软件需求的理解，避免对开发人员需求产生误解。 制作术语表，定义说明项目应用领域的专业术语。 项目相关人员易于统一理解SRS中的专业名词、专有名词、俗语和约定语。 另外，p 29，7/16，定义需求开发过程定义项目的前景和范围，用户组选择产品的代表可以确定使用实例，响应于系统事件进行进一步需求获取讨论，观察用户如何检查问题报告的需求重用性，以及3.2获取需求的方法前景是描述所有利益相关者实现产品目标的共识范围，定义了需求是否属于特定版本的边界。 使用P30、产品用户组，防止忽略某个用户组的需求。 为各类用户至少选择一名代表他们需求的用户代表，他们有时间、有热情、有权参与需求工作。 召集同类产品或产品之前版本的用户代表，从他们那里收集当前产品的功能需求和非功能需求。 另外，从用户代理处收集使用软件完成必要任务的记述的用例，研究用户与系统之间的交互方式和交互要求。 列出系统可能发生的外部事件，以及每个事件的预期响应时间。 专业的获得需求研讨会便于分析师与客户的合作。 观察用户执行业务的过程。 画简单的数据流程图和业务流程图，描述用户何时获取数据以及如何进行业务处理。 客户针对当前系统的问题报告和补充需求，为新产品或新版本提供了更多改进和特性的思路。 如果客户要求的功能与现有产品类似，则可以确保要求具有可重复使用现有软件组件的灵活性。 8/16，3.3需求分析方法，建立关联图确定开发原型分析需求的可行性，为需求建立模型，制作数据字典，将需求分解为子系统，应用质量功能配置，P32，质量功能配置(QFD )是高级系统技术，将产品功能、属性和对客户的重要性相结合。 QFD把需求分为期待需求、普通需求和兴奋需求三类。 定义系统和外部实体的边界和接口。 (第5章)开发者和用户无法确定需求时，可以构筑开发原型。 这更直观地阐明了许多概念和可能发生的事情。 通过评价原型，可以更好地理解需要解决的问题。 (第13章)在可接受的成本、性能要求下，分析各需求实施的可行性，明确与各需求相关的风险。 与其他需求冲突，包括对外部因素的依赖和技术障碍。 通过创建数据字典来定义系统使用的所有数据项和数据结构。 (第十章)包括多个子系统在内的复杂产品需求必须分配给各自的软件、硬件和人员子系统和部件。 需求的图形分析模型是SRS的优秀补充说明。 这样的模型包括数据流图、实体关系图、状态转移图、对话图、对象类、交互图等。 (第11章)应用分析方法，决定实现use-case、产品特性或个别需求的优先顺序。 根据优先级确定产品版本中必须包括的需求和特性。 (第十四章)。 创建9/16和3.4SRS的方法需要使用SRS模板来指明需求来源定义记录在每个需求附注中的业务规格的质量属性，并定义用于创建SRS的标准模板。 此模板提供了统一的文档结构。 创建SRS时，可以根据项目的特性适当地修剪标准模板。 (第十章)澄清各需求的来源。 该来源既是use-case或其他客户的要求，也是某一高层系统需求、商业规范、政府法规、标准或其他外部来源。 (第十八章)为SRS中的每个需求提供独立的可识别符号或符号。 记录需求变更，并建立需求状态与变更作业的计量。 (第10章)业务规范是软件的操作原则，将谁在什么情况下能够采取什么样的行动写作SRS的独立部分。 一些业务规范引出相应的功能需求(第九章)，但除功能需求外，还应考虑性能、效率、可靠性、可用性等非功能的质量属性。 (第12章)、p3、10/16、3.5需求验证的方法、审查需求文件制作测试用例以确定合格标准、记述产品的功能和性能、确定软件的使用环境和开发条件，明确软件的合格判定标准。P34、非正式正式审查由客户、分析人员、设计人员、检查员组成的SRS和相关模型。 根据用户需求导出功能测试用例，记录产品应在特定条件下的行为。 11/16，定义变更管理流程设立变更管理委员会，进行变更影响分析，建立基准，使用追踪需求文件版本管理变更历史记录，测量需求稳定性的需求管理工具，制作需求追踪矩阵，决定3.6需求管理方法，P35，选择、分析、决定需求变更的流程。 我们声称所有需求变更都应遵循此流程，并使用软件工具支持变更管理流程。 (第十九章)设立变更管理委员会，决定需求变更的评价，设定优先顺序，制定目标版本。 (第十九章)评估需求变化，以确定对项目计划和其他需求的影响。 (第19章)确立需求的基线，确定需求的版本号，以免混淆新旧版本。 (第18章)记录SRS变更的日期、变更内容、原因、更新担当者、新版本号等。 创建数据库并存储每个功能要求的关键属性，如建议、通过、实施和验证。 的双曲馀弦值。 的双曲馀弦值。 的双曲馀弦值。 的双曲馀弦值。 记录在基线上设置的需求数和周/月更改，以衡量需求的稳定性。 需求管理工具存储不同类型的需求，确定各需求的属性，跟踪其状态，在需求与其他软件工作产品之间建立跟踪链(第20章)，建立需求跟踪能力矩阵，将各功能需求与实现它的设计和代码、测试用例相结合，将功能需求与业务需求、用户(第20章)，12/16，选择适当的生存周期，根据需求协商项目计划，回顾合同管理的需求风险追踪需求，总结教训。 3.7项目管理方法，P36，选择合适的生存周期是在软件项目管理的基础上，常用的软件系统开发周期模型主要是瀑布模型、螺旋模型、渐进模型和原型模型。 首先，根据项目的设想和范围，可以估算开发功能所需的工作量，随着需求的明确和完善，项目开发计划的时间表不断变化。项目实现与管理相结合，与客户、开发人员、测试人员一起确定有效、快速协商、合同机制。 记录与需求相关的项目风险。 以各种方式降低或阻止风险。 记录需求开发和管理活动的工作量。 评估计划需求活动是否满足预期要求，并提供未来项目需求工程所需资源的计划。 认真回顾、收集和分析过去项目的经验教训，帮助项目管理者和需求分析者在今后的工作中不要绕道。 13/16，3.8方法的使用原则，从低到高，先难的使用原则。 (参照表3-2 )方法的有效性判定原则。p8、15/16、3.9需求开发过程、p9、图3-2需求开发反复示意图、15/16、本章总结需求工序领域的方法包括需求开发方法和需求管理方法，共计7种46个。 需求开发方法共计27个，其中需求获取方法为11个，需求分析方法为8个，需求编制方法为5个，需求