第2章_软件工程与需求工程
第2章-软件需求与软件需求规约
6
（3）应用
针对一个小型简单的系统，运 用合适的需求求发现技术，按 一定要求的规格说明格式，以 限定的自然语言给出该系统的 需求规约。
7
软件需求及系统/产品(需求)规约
不论是自顶向下的软件开发,还是自底 向上的软件开发,正确定义问题,是解决 问题的前提.
1
课 名：
软件工程
2
2
第1章 第2章 第3章 第4章 第5章 第6章 第7章 第8章
绪论 软件需求与软件需求规约 结构化方法 面向对象的方法——UML 面向对象的方法——RUP 软件测试 软件生存周期过程与管理 集成化能力成熟度模型（CMMI）
3
第2章 软件需求与软件需求规约
软件需求以一种技术的形 式，描述一个产品/系统应该 具有的功能、性能和其他性 质。
第一个问题：依据需求工程人员的技能和产品、合同的 实际情况，往往需要“组合”地使用这些技术来开发 初始需求。
第二个问题：在任意特定的环境中，在实施上述任何一 项技术时，还都可以辅以诸如原型构造等其他方法， 例如，在举行小组会时可以使用原型，方便人员之间 的交流。
第三个问题：执行需求发现这项活动的人，其技能水平 对这项活动的成功具有重大的影响。
--硬件限制(Hardware limitations)，例如：处理速度 、信号定序需求、存储容量、通讯速度以及可用性等；
--与其它应用接口(Interfaces to other applications) ，如，当外部系统处于一个特定状态时，禁止新系统某些 操作
--并发操作(Parallel operations)，例如，可能要求从/ 自一些不同的源，并发地产生或接收数据。对此，必须清 晰地给出有关时间的描述。
软件工程中的需求分析与验证
需求识别、需求分 类、需求确认
验证需求是否符合 客户期望
数据流图、状态图、 用例图
需求跟踪管理
追踪需求的变化
需求文档的编写
需求文档的格式规范
包括标题、介绍、需求描述等
需求文档的书写技巧
清晰明了、避免歧义、扼要概括
需求文档的审查与评审
团队内部、客户反馈
需求变更管理
需求变更的原因
需求不清晰 新需求的出现 客户需求变更
● 02
第2章 需求管理过程
需求识别与获取
在软件工程中，需求来源可以包括客户需求、 用户需求、系统需求等。需求获取的方法包括 访谈、问卷调查、头脑风暴等。确定需求优先 级可以帮助团队更好地安排工作。需求变更管
理是确保需求变更过程可控的重要环节。
需求分析与建模
需求分析的步骤
需求验证与确认
需求建模方法
工具A在项目X中的 应用
工具C在项目Z中的 应用
工具B在项目Y中的 应用
工具D在项目W中 的应用
成功检测到需求缺 陷，提高产品质量
发现安全漏洞，提 前修复风险
有效评估系统性能， 确保用户体验
减少人力投入，节 约测试成本
● 05
第五章 需求工程的实践案例
案例一：在线教育平台需求分析
案例背景
分析在线教育市场趋势
案例二：智能家居系统需求管理
案例介绍
介绍智能家居系统的背景和目 标
需求获取过程
需求变更处理
需求跟踪与确认
通过用户访谈和调研获取需求
如何处理需求变更，维护系统 稳定性
如何跟踪需求的实现情况，并 确认需求是否满足用户期望
案例二：智能家居系统需求 管理
智能家居系统的需求管理是一个复杂的过程， 涉及到用户习惯、安全性、互联性等多方面的 考量。通过合理的需求获取、变更处理和跟踪 确认，可以有效提高系统的稳定性和用户满意
软件工程第二章(可行性分析)
（5） 交付的产品清单。
项目开发计划书供软件开发单位使用。
小结：
1、项目的问题定义、可行性分析和项目计划是总体 规划阶段的工作，重点是项目的可行性分析。
2、可行性分析主要从技术可行性、经济可行性和操 作可行性三方面来分析该项目是否值得开发。
3、可行性分析最后形成的成果是可行性分析报告。
项目的筹备、规划与准备是软件项目实施的前
期工作，它由两个重要的工作阶段构成：一是
项目规划及可行性分析；二是项目需求分析。
一、可行性分析的概念
可行性分析就是解决一个项目是否有可行解以及是
否值得去解的问题。该阶段的主要任务就是用最小
的代价在尽可能短的时间内确定问题是否能够得到 解决。
二、可行性分析的目标和内容
等。
(6) 技术可行性(技术风险评价)：技术实力分析、已有的 工作及技术基础和设备条件等等。 (7) 法律可行性分析结果描述。 (8) 可用性评价：汇报用户的工作制度和人员的素质，确 定人机交互功能界面需求。
(9) 其他项目相关的问题：如可能会发生的变更等等。
可行性研究报告由系统分析员撰写，交由项目负责人审查， 再上报给上级主管审阅。 在可行性研究报告中，应当明确项目“可行还是不可行”， 如果认为可行，接下来还要制定项目开发计划书。
识别用户要求 评价系统的可行性 进行经济分析和技术分析 把功能分配给硬件、软件、人、数据库和其它系 统元素 建立成本和进度限制 生成系统规格说明，形成所有后续工程的基础
三、 可行性分析的主要任务
具体地说，分析员应从下面三个方面对项目做出可行性分 析： （1）技术可行性：使用现有的技术能实现这个系统吗? （2）经济可行性：这个系统的经济效益能超过它的开发成本 吗?（详细在后面介绍成本/效益分析） （3）操作可行性：系统的操作方式在该用户组织内行得通吗?
软件设计 Zhou Su 第2章 理解需求
领域活动。
2.1 需求工程
• 在项目起始阶段中，要建立起基本的理解，包括对问题、 谁需要解决方案、所期望解决方案的性质、项目干系人和 开发人员之间达成初步交流合作的效果等。
2.1 需求工程
• （2）导出 • 询问客户、用户和其他人，系统或产品的目标是什么，想 要实现什么，系统和产品如何满足业务的要求，最终系统 或产品如何用于日常工作。这些问题看似简单，但实现却 很困难。
2.3.1 协同收集需求
• 已经有了很多不同的协同需求收集方法，各种方法适用于 稍有不同的场景，而且所有这些都以下面这些原则为基础：
– 会议由软件工程师和其他的利益相关者共同举办和参与。 – 制定筹备和参与会议的规则。 – 拟定一个会议议程，这个议程既要足够正式，使其涵盖所有的重 点；但也不能太正式，以鼓励思想的自由交流。 – 由一个“调解人”（可以是客户、开发人员或其他人）控制会议。 – 采用“方案论证手段”（可以是工作表、活动挂图、不干胶贴纸 或电子公告牌、聊天室或虚拟论坛）。
供指导。
2.1 需求工程
• （6）确认 • 在这一步将对需求工程的工作产品进行质量评估。需求确 认要检查规格说明以保证：已无歧义地说明了所有的系统 需求；已检测出不一致性、疏忽和错误并得到纠正；工作 产品符合为过程、项目和产品建立的标准。
2.1 需求工程
• 正式的技术评审是最主要的需求确认机制。确认需求的评 审小组包括软件工程师、客户、用户和其他利益相关者， 他们检查系统规格说明，查找内容或解释上的错误，以及 可能需要进一步解释澄清的地方、丢失的信息、不一致性 （这是建造大型产品或系统时遇到的主要问题）、冲突的 需求或是不可实现的（不能达到的）需求。
– 如何描述由某成功的解决方案产生的“良好”输出的特征？ – 该解决方案强调解决了什么问题？ – 能向我们展示（或描述）解决方案使用的商业环境吗？ – 存在将影响解决方案中特殊的性能问题或约束吗？
软件工程专业优质课软件需求工程
软件工程专业优质课软件需求工程软件工程专业优质课——软件需求工程软件需求工程是软件工程领域的一门重要课程，它主要关注软件项目中的需求分析、规划与管理。
通过系统地收集、分析和定义用户对软件系统的需求，软件需求工程可以帮助开发团队更好地理解用户需求，并将其转化为可执行的开发计划。
下面将从需求工程的基本概念、流程和关键技术等方面进行论述。
一、需求工程的基本概念软件需求工程是指在软件开发或系统维护过程中，对需求进行收集、分析、定义、验证与管理等一系列活动的过程。
它的目标是构建一个正确、完整、准确、一致和可追踪的需求规格说明，为软件开发提供基础。
需求工程的核心是要确保需求的正确性和完整性。
只有对用户需求进行准确的理解和把握，才能保证软件开发过程中的目标和结果与用户的期望保持一致。
因此，需求工程在整个软件开发过程中具有举足轻重的地位。
二、需求工程的流程需求工程的流程可以分为需求获取、需求分析、需求定义、需求验证和需求管理等五个阶段。
1. 需求获取阶段需求获取阶段主要通过面对面交流、问卷调查、访谈和文献分析等方式，与用户直接沟通以获取需求信息。
在这个阶段中，需求工程师需要充分了解用户的背景、目标和需求，明确项目的范围和目标，以确保需求的准确性和一致性。
2. 需求分析阶段需求分析阶段是对需求进行详细分析和整理的过程。
在这个阶段中，需求工程师会对需求进行分类、排序和整理，以便更好地理解和表达需求。
同时，需求工程师还需要识别需求之间的相互关联和依赖，并找出潜在的冲突和问题。
3. 需求定义阶段需求定义阶段是将需求转化为可执行的设计和规划的过程。
在这个阶段中，需求工程师需要将需求进行详细描述，并明确需求的优先级和可实现性。
同时，还需要与开发团队共同讨论和协商，确立一个合理的开发计划和时间表。
4. 需求验证阶段需求验证阶段是对需求的正确性和完整性进行验证的过程。
在这个阶段中，需求工程师会与用户进行沟通和协商，共同确认和验证需求的准确性和可行性。
软件工程第二章软件过程
第二章：软件过程目标：软件工程和软件过程模型的概念；了解3个一般的软件过程模型及何时使用它们；了解软件需求工程，软件开发，测试和进化中所涉及的基本过程活动；理解为什么软件过程要有效地组织以应对软件需求和设计上的变更；了解Rational统一过程是如何集成好的软件过程实践来产生一个可适应的软件过程。
所有的软件过程都必须具有4种对软件工程来说是基本的活动。
它们是：1.软件描述：必须定义软件的功能以及软件操作上的约束。
2.软件设计和实现：必须生产符合描述的软件。
3.软件有效性验证：软件必须得到有效性验证，即确保软件是客户所想要的。
4.软件进化：软件必须进化以满足不断变化的客户需要。
2.1软件过程模型一软件过程模型一般有1.瀑布模型：该模型将基本的过程活动，描述，开发，有效性验证和进化，看成是一些界限分明的独立的过程阶段，例如，需求描述阶段，软件设计阶段，实现阶段，测试阶段，等等。
2.增量式开发：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统的开发是建立一系列的版本（增量），每个版本添加部分功能到先前的版本中。
3.面向复用的软件工程：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统开发过程着重于集成这些组件到新系统中，而非从头开发。
2.1.1瀑布模型一瀑布模型中的主要阶段直接映射基本的开发活动：1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护二适合采用瀑布模型的时候瀑布模型是与其他工程过程模型相一致的，在它的每个阶段都要生成文档。
这使得过程是可见的，项目经理能够根据项目计划监控项目的过程。
它的主要问题在于它将项目生硬地分解成这些清晰的阶段。
关于需求的责任和义务一定要在过程的早期阶段清晰界定，而这又意味它对用户需求变更的响应较困难。
所以只有在对需求了解的好，而且在系统开发过程中不太可能发生重大改变的时候，适合采用瀑布模型。
瀑布模型的一个重要变形是形式化系统开发。
软件工程第2章-系统工程
软件工程第2章-系统工程软件工程第2章-系统工程2.1 系统工程概述系统工程是一种系统性和综合性的工程方法，旨在设计、开发和维护复杂的软件系统。
系统工程的主要目标是满足用户需求，并确保系统的有效性、可靠性和可维护性。
2.1.1 系统工程定义系统工程是一个跨学科的领域，涉及到多个专业领域的知识和技术。
它集成了工程学、计算机科学、信息技术等多个学科的理论与实践，以解决大规模软件系统开发和维护过程中的各种问题。
2.1.2 系统工程过程系统工程的过程涵盖了软件系统的整个生命周期，包括需求分析、设计、开发、测试、部署和维护等阶段。
每个阶段都有特定的任务和活动，并且需要进行严格的管理和控制。
2.1.2.1 需求分析阶段需求分析阶段是系统工程的起点，通过与用户沟通和交流，收集和整理用户需求，并将其转化为系统的功能和性能要求。
2.1.2.2 设计阶段在设计阶段，系统工程师会根据需求分析阶段的成果，设计整个系统的结构和组件之间的关系。
这包括系统架构设计、模块设计和接口设计等。
2.1.2.3 开发阶段开发阶段是系统工程中最为关键的阶段，主要是根据设计阶段的成果，进行软件编码、集成和测试。
开发人员需要按照设计规范和编码标准进行开发工作，并保证代码的质量和可维护性。
2.1.2.4 测试阶段测试阶段是为了验证系统是否满足用户需求，并发现和修复潜在的缺陷和问题。
测试人员会执行各种测试活动，包括单元测试、集成测试和系统测试等。
2.1.2.5 部署阶段在部署阶段，系统工程师会将已经通过测试的系统部署到目标环境中，并进行安装、配置和调优等工作，确保系统能够正常运行。
2.1.2.6 维护阶段维护阶段是系统工程的最后一个阶段，主要是为了确保系统能够持续地运行和满足用户的需求。
维护人员会定期检查系统的性能和可靠性，并进行必要的修复和优化等工作。
2.2 系统工程的关键技术2.2.1 需求工程需求工程是系统工程中非常重要的一环，它主要涉及到需求获取、需求分析、需求验证和需求管理等方面的内容。
软件工程基础(胡思康)第2章
软件需求工程
S
1
2
软件需求的基本概念 需求工程的过程
3
需求获取技术
4
结构化需求分析和建模
5 案例：简历自动获取和查询系统的需求建模
6
需求评审
➢实际项目经验表明：用户自身对将要开发的系统 也并不是完全理解，对需求目标的陈述带有主观片 面性、模糊性、不一致性，甚至还会出现错误；用 户不会把需求按照功能、性能、行为、约束等特性 对需求分门别类。
➢对传统的需求变更管理过程来说，主要包括软件配置、软 件基线和变更审查。
软件基线由一组软件配置项组成。当软件配置项处于稳 定状态后（如需求文档经过评审以后），就确定了这组软 件配置项的基线。在后续的开发过程中，软件配置项发生 变更，则这一变更须通过变更审查并确定，变更才能记录 在软件配置项中，并通知与之有关的人员。
基线是进行需求变更的界线。在需求分析的基线定义 之前，能够随时进行需求变更，若在基线定义之后变 更，则需要重新进行审查和复审。
功能是否有约束，系统如何使用更能符合用户的操作习 惯。在需求评审中，软件人员需要在用户的配合下，对 需求规格说明进行管理复审，以确保和用户对需求规格 说明的理解达成一致。
数据从哪里来（收集过程），到哪里去（存储过程）， 系统内部如何操作和转换这些数据，如果表示数据，如 何共享数据等问题。 数据分析将数据从物理实体映射 为逻辑实体，分析逻辑数据间的连接、视图模型。
把问题域中的问题转换成信息领域 问题。结构化方法采用数据流图、 数据字典等图形工具定义。面向对 象方法采用例图、类-对像图。
➢对传统的需求变更管理过程来说，主要包括软件配置、软 件基线和变更审查。
软件配置的目的是确保所做的工作是可回朔的，能够恢 复原来工作的文档、代码等内容，也能跟踪目前工作结果 的来龙去脉。需要进行软件配置的内容称为软件配置项， 主要有两类：一是属于产品自身需要的内容，如开发文档、 代码、数据等；二是为软件产品服务的内容，如进度计划、 人员安排、报告等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
不足
◦ （1）在把每个新增的构件或功能集成到现有的软件系统中时，必 须不破坏该软件系统。
◦ （2）在设计软件系统的体系结构时，要充分考虑到其开放性，而 且加入新构件的过程必须简单和方便。
Software Requirements Engineering
11
2.2.4 螺旋式模型
将瀑布式模型与快速原型模型结合到一起，并加上风 险分析。理解这种模型的一个简便方法是把它看作在每个 阶段之前都增加风险分析。
累计费用
各步骤的进度
确定目标， 选定方案， 设定约束条件
风险分析 风险分析 风险分析
评估方案， 识别并排除风险
需求计划 与生命周
期计划
开发计划
风险 分析
原型1
操作概念
需求确认
原型2
软件需 求
可运行的 原型3 原型
软件 产品 设计
详细 设计
时间
单
元 编码
计划下一阶段
集成 测
实现
验收 测试 试 测试
开发、验证 下一级产品
– 软件开发过程、软件开发和维护的方法和技术、软件开发和维护 工具系统、质量评价和质量保证、软件管理和软件开发环境等。
Software Requirements Engineering
4
2.2 软件开发过程模型
1. 瀑布式模型 2. 快速原型模型 3. 渐增式模型 4. 螺旋式模型 5. 面向对象的开发模型
需求分析和定义
（概要）设计
实现与集成各个构件
测试
维护
渐增式模型表明，必须在实现各个构件之 前就全部完成需求分析和概要设计工作。
Software Requirements Engineering
10
2.2.3 渐增式模型
特点
◦ （1）能在短时间向用户提交可完成部分功能的产品。 ◦ （2）能逐步增强产品功能以使用户有较充裕的时间学习和适应新
• 局限性
– （1）风险分析执行的困难使螺旋模型仅适用于大规模软件项目
Software Requirements Engineering
13
2.2.5面向对象的开发模型
所谓面向对象就是应 用对象、类、继承、封装、 消息、对象或类之间的关 系等面向对象的概念对问 题进行分析和求解的软件 开发技术，或者说，是以 对象（类）为数据中心、 对象之间的动态行为模式 作为运行机制的一种问题 求解方法。
Software Requirements Engineering
12
2.2.4 螺旋式模型
• 特点
– （1）适用于软件开发机构内部开发大规模软件项目。 – （2）对于可选方案和约束条件的强调有利于已有软件的重用，也
有助于把软件质量作为软件开发的一个重要目标。 – （3）减少过多测试或测试不足所带来的风险。
Software Requirements Engineering
5
2.2.1瀑布式模型
依据软件生命期而提出的软件开发模型 ，将软件的开 发过程被分为六个阶段，每个阶段都有明确的分工和任务， 并产生一定的书面结果。各阶段之间是紧密相关的，后一 阶段的工作是依据前一阶段的工作结果而开展的。
软件计划
需求分析与定义
7
2.2.2快速原型模型
快速原型模型的基本思想是快速建立一个实现了若干 功能的（不要求完全）可运行模型来启发、揭示和不断完 善用户需求，直到满足用户的全部需求为止。
收集需求 快速设计 建立原型 评价并细化需求 设计与实现 测试 维护
Software Requirements Engineering
Software Requirements Engineering
14
2.2.5面向对象的开发模型
• 特点
（1）有一部分分析工作必须在设计之前进行，而另 外一些分析工作则需与其他部分的设计与实现工作 并行地进行，因而呈现出非线性的工作方式。 （2）软件系统的表达形式在整个开发模型中都是相 同的，即面向对象方法中把类及其结构作为系统的 表达单元，无论哪一个阶段都以渐增的方式不断地 进化或细化这些表达单元。 （3）开发模型支持软件的重用。
– （1）大型软件系统十分复杂，很难理解和维护； – （2）软件开发周期过长； – （3）大型软件系统的可靠性差； – （4）软件费用往往超出预算。
Software Requirements Engineering
3
• 软件危机的解决方法
– 应用工程化的方法来进行软件的开发和维护
• 软件工程的研究内容
设计
编码
测试
维护
Software Requirements Engineering
6
2.2.1瀑布式模型
• 不足
– （1）要求用户一开始就提出清晰完整的需求 ；
– （2）段间移交信息（文档）的过程中，由于个人的理解不同， 容易产生误解；
– （3）用户的参与程度不够。
Software Requirements Engineering
不足
◦ （1）用户易于视原型为正式产品；
◦ （2）快速原型系统对于软件系统的开发环境要求较多，在一定程 度上也影响了其使用的范围和实用价值。
Software Requirements Engineering
9
2.2.3 渐增式模型
渐增式模型的基本思想是从核心功能开始，通过不断 地改进和扩充，使得软件系统能适应用户需求的变动和扩 充，从而获得柔软性较高的软件系统。
8
2.2.2快速原型模型
目的
◦ （1）明确并完善需求； ◦ （2）探索设计选择方案； ◦ （3）可以发展为最终的产品。
特点
◦ （1）能弥补瀑布模型中用户参与程度不够等不足； ◦ （2）能减少用户需求的遗漏以及（在软件开发后期）用户频繁修
改需求的可能性 ； ◦ （3）用户可以充分地参与到软件开发中； ◦ （4）快速。
Software Requirements Engineering
15
2.3 需求工程与软件开发
1. 需求工程对软件开发的影响 2. 需求工程面临的困难
Software Requirements Engineering
16
2.3.1 需求工程对软件开发的影响
第2章 软件工程与需求工程
第2章 软件工程与需求工程
2.1 软件工程 2.2 软件开发过程模型 2.3 需求工程与软件开发 2.4 软件需求的开发和管理过程
Software Requirements Engineering
2Байду номын сангаас
2.1 软件工程
• 软件危机
– 是指人们难以控制软件的开发和维护。
• 表现