01软件需求基础知识

1、软件需求工程Software Requirements Engineering( SRE )第一部分 需求工程综述第一章 软件需求基础龚 永 罡2022/8/111学习目标在学完本章内容之后，你应该能够： 理解软件需求工程的关键名词； 理解需求开发与需求管理的区别； 了解劣质需求的特征； 掌握优质需求的特点。 2/19关于项目涉众我们称参与软件项目或受软件项目影响的人为项目干系人，或称为项目涉众，主要包括： 客户：为达到业务目标而投资项目或购买产品 用户：直接或间接使用产品 需求分析员：负责获取和编写需求 开发人员：根据需求文档设计、实现、维护软件 测试人员：检测产品的分析、设计、实现与预计的

2、一致 文档编制人员：负责编写用户手册、用户培训资料和帮助系统 法律人员：保证产品的合法性和知识产权 生产人员：制造包含该软件的产品 其他人员：市场策划、营销、技术支持以及其他辅助人员 3/19 需求工程是一个相对较新的术语，它包含着与发现、记录和维护计算机系统的需求相关的所有活动。 术语“工程”的使用意味着，应该采用系统的和可重复的技术来确保系统需求是完整的、一致的和相关的。 术语“需求工程”是从系统工程的角度定义的。如果从商业系统角度来讲，也可以把需求工程看作是“系统分析”。关于需求工程将自然科学理论应用到具体的工农业生产部门中形成的各学科的总称。如水利工程、化学工程、土木工程 4/191.

3、1 软件需求的定义 1) 定义IEEE (美国电气和电子工程师协会) 软件标准词汇表定义需求为：用户解决问题或达到目标所需要的条件或权能 (Capability 天分、潜能：一种可以得到发展应用的才能或能力 【美国传统词典】)。系统或系统部件要满足合同、标准、规范或正式规定文档所需具有的条件或权能。一种反映上面(1)或(2)所描述的条件或权能的文档说明。P5 5/19第3层 功能需求层第1层业务需求层业务需求远景与范围文档1.1 软件需求的定义 2) 需求的层次第2层用户需求层用户需求用例文档质量属性业务需求图1-1 需求关系图功能需求系统需求外部界面约束条件软件需求规范和模型功能性需求非功能

4、性需求P6 6/19软件需求包括三个不同层次需求：业务需求用户需求功能需求与非功能需求描述用户使用产品必须完成的任务，通过使用实例（ use-case ）文档予以说明。1.1 软件需求的定义 2) 需求的层次P7定义开发人员必须实现的软件功能，用户通过这些功能完成他们的日常工作和任务，以满足业务需求。通过软件需求规范给予说明。描述系统展现给用户的行为和执行的操作等，包括质量属性、操作界面细节、性能要求、约束条件、应遵从的标准与规范等。通过软件需求规范和模型给予说明。业务：个人或某个机构的本行业本职工作。反映组织或客户对系统、产品高层次的目标要求；通过项目远景与范围文档予以说明。 7/191.1

5、 软件需求的定义 3) 需求定义的要点软件需求定义 “做什么？” ，不描述“怎么做？”需求规格说明（SRS software requirements specification) 重点描叙产品应达到和满足的功能与非功能需求特性。软件开发与运行环境、开发进度、产品成本、培训需求等内容应该在项目需求中进行定义。P8 8/191.2 软件需求的开发和管理软件需求开发软件需求管理软件需求工程 可以将整个软件需求工程领域划分为需求开发和需求管理。前者产生经过验证的SRS；后者以SRS为基线，对需求变更进行控制、管理。P9已通过正式复审和批准的规约或产品，它将作为进一步开发的基础，并且只能通过正式的变化

6、控制过程来改变。 9/191.2 软件需求的开发和管理图1-2 软件需求工程的组成需求工程需求开发获取需求验证 SRS需求分析编写 SRS需求管理控制变更跟踪状态控制版本跟踪需求P9 10/191.2 软件需求的开发和管理1) 需求开发阶段活动获取确定产品所期望的用户类。 获取每个用户类的需求。 了解用户的任务和需求，以及这些任务要实现的业 务目标。分析分析源于用户的信息，将用户的任务目标与功能需求、非功能需求、业务规则、解决方法建议及其他无关的信息区分开来。将系统级需求分解为子系统，将需求分配给组件。了解相关质量属性的重要性。商讨实施优先级的划分。规格说明 将所收集的用户需求编写成规格说明和

7、模型验证 评审规格说明，确保对用户需求达到共同的理解与认识 在整个开发小组接受规格说明之前解决需求分歧P9 11/191.2 软件需求的开发和管理2) 需求管理阶段 活动版本控制 定义需求基线变更控制 评审需求变更请求，评估变更可能产生的影响，以决定是否批准 保持项目计划与需求的同步 以一种可控制的方式将需求变更融入到项目中 估计变更需求所产生的影响，并在此基础上协商新的约定需求跟踪 让每项需求都能与对应的设计、源代码、测试用例联系起来，以实现需求跟踪需求状态跟踪在整个项目过程中，始终跟踪需求状态及其变更情况P10 12/19需求管理需求变更过程当前基线修正后基线需求变更项目环境市场、客户、管

8、理者项目变更1.2 需求的开发和管理3）开发与管理的分界需求开发市场、客户、管理者需求分析 记录审阅 协商基线需求图1-3 需求开发与需求管理的分界P10 13/191.3 所以项目都有需求 开发软件过程中最为困难的部分是对要开发什么作出准确的判断。 所以概念性工作中最难的是建立详细的技术需求，包括所有与用户、机器和其他软件系统的接口。这部分工作的错误对最终系统的破坏最大，也最难纠正。一个没有经过用户确认的需求，不可能得到好的结果。P10 14/191.4 不合格的SRS产生的原因 用户参与不够（认识不到位）； 用户需求不断变化（易变性）； 用户需求模棱两可（不确定性）； 不必要的特性（没有抓

9、主要矛盾） ； SRS不符合要求（没有强调质量）； 用户分类不到位（分析不全面）； 计划不准确（计划没有反映实际情况）。P12 15/191.5 优质需求过程的好处 在开发后期和维护阶段重做的工作将大大减少。 节约开发成本。 能弥补用户期望和开发者实际开发之间的“鸿沟”，能使产品更富有吸引力，能拥有忠实的客户关系。 将需求明确地分配到各软件子系统，能简化硬软件的集成，也能确保软硬件系统功能匹配适当。 能降低需求变更带来的负面影响。 有利于系统测试，确保产品质量。P14 16/191.6 优秀需求的特点1) 需求陈述的特点 完整性正确性可行性必要性优先性无二义性可验证性每项需求都必须将所要实现的

10、功能描述清楚。每项需求都必须准确地陈述其要开发的功能。每项需求都必须是在已知系统和环境的能力和限制范围内可以实现的。每项需求都应把客户真正所需要的和最终系统所需遵从的标准记下来。给每项需求、特性分配一个实施优先级，以指明它在特定产品中所占的分量。对所有需求说明的读者都只能有一个明确统一的解释。每项需求都能通过设计测试用例或其它验证方法。P15 17/191.6 优秀需求的特点2) SRS 的特点 完整性 一致性 可修改性 可跟踪性不遗漏任何必要的信息。与其它软件需求或高层（系统、业务）需求不相矛盾。每项需求独立标出，并与别的需求区别开来，无二义性；每项需求在SRS中只出现一次；使用目录表、索引和相互参照列表方法，使SRS更容易修改。每