《软件需求分析》需求管理PPT课件
合集下载
(完整版)《软件需求分析》PPT课件
4.1.1 需求分析的特点
需求分析虽处于软件开发过程的开始阶段，但它对 于整个软件开发过程以及软件产品质量是至关重要 的。需求分析是指开发人员要进行细致的调查分析， 准确理解用户的要求。将用户非形式的需求陈述转 化为完整的需求定义，再由需求定义转换到相应的 形式功能规约的过程。
2020/4/10
2020/4/10
广东工业大学计算机学院
11
（4）用户界面需求：用户操纵界面的形式、输入 /输出数据格式、数据传递的载体等。
（5）系统的可靠性、安全性、可移植性和可维护 性等方面的需求。
2020/4/10
广东工业大学计算机学院
12
2. 导出软件的逻辑模型
分析人员根据前面获取的需求资料，要进行一致性 的分析检查，在分析、综合中逐步细化软件功能， 划分成各个子功能。同时对数据域进行分解，并分 配到各个子功能上，以确定系统的构成及主要成分。 最后要用图文结合的形式，建立起新系统的逻辑模 型。
2020/4/10
广东工业大学计算机学院
10
1. 问题明确定义
（1）功能需求：指所开发的软件必须具备什么样 的功能。
（2）性能需求：要开发软件的技术性能指标，如 访问时延、存储容量、运行时间等限制。
（3）环境需求：软件运行时所需要的硬件的机型、 外设；软件的操作系统、开发与维护工具和数据库 管理系统等要求。
2020/4/10
广东工业大学计算机学院
5
3. 交流障碍
需求分析涉及人员较多，系统分析员要与软件系统 用户、问题领域专家、需求工程师和项目管理员等 进行交流。但是这些人具备不同的背景知识，处于 不同的角度，扮演不同角色，造成了相互之间交流 的困难。
2020/4/10
《软件需求分析》课件
关系定义
定义实体之间的关系，如 关联、依赖、聚合等。
实体关系图绘制
使用图形化工具绘制实体 关系图，展示实体之间的 关联关系。
Part
04
需求规格说明
需求规格说明编写
确定需求来源
明确软件需求来自哪些方面，如用户、市场、技术等 ，确保全面覆盖。
编写规范统一
遵循统一的编写规范，确保需求规格说明的清晰、准 确和一致性。
需求分析的过程
需求调研
通过与用户沟通、调查问 1
卷、现场观察等方式，了 解用户需求和业务场景。
需求确认
4
将分析出来的需求与用户 进行确认，确保双方对需 求的理解一致。
需求分析
2
对收集到的需求进行整理
、分类、抽象，形成系统
需求。
需求评审
3 对分析出来的需求进行审
查和评估，确保需求的正 确性和完整性。
访谈技巧
注意倾听、引导和追问，以获得深入的需求 信息。
记录和分析
详细记录访谈内容，并进行分析，提取关键 需求。
问卷调查
设计问卷
根据软件的功能和目标，设计合理的问卷。
选择调查对象
确保调查对象的代表性和广泛性。
发布和收集问卷
通过适当的渠道发布问卷，并确保问卷的完整性和准确性。
数据分析
对收集到的数据进行统计分析，提取关键需求。
详细描述
社交网络平台用户数量庞大，用户交互频 繁，对系统的可用性和响应速度要求极高 。同时，由于社交网络平台的功能更新频 繁，需求变化较快，需求分析需要关注系 统的可扩展性和灵活性。此外，社交网络 平台还需要考虑用户隐私和数据安全等问 题。
THANKS
感谢您的观看
非功能需求定义
第3章 软件需求分析PPT课件
使用原型系统的主要目的,是使用户通过实践获得关于未来的系统 将怎样为他们工作的概念，检验关键设计方案的正确性和检验系统是 否真正满足用户的需要，从而可以更准确地提出和确定他们的要求。 用户试用了原型系统以后，能够指出系统的哪些特性是他们喜欢的， 哪些是他们感到不能接受的，以及他们还需要哪些新的功能。根据经 过实践检验的用户需求而开发出来的系统，更可能真正满足用户的需 要。特别是当所开发的系统是全新的，用户没有使用类似系统的经验 时，更应该认真考虑开发原型系统的必要性和可能性。
8
3.2 软件需求分析的步骤
3.2.1 问题的分析
▪ 首先，系统分析员应该仔细研究可行性分析报告和软件项 目实施计划，确定软件的需求，并提出这些需求的实现条 件及应该达到的标准。
▪ 其次， 问题分析是建立分析所需要的通信途径，以保证 顺利地分析问题。
▪ 再次，在问题分析过程中还必须充分重视和使用数据流图、 数据字典和算法描述工具。
（6）设计的限制条件是现实的吗?
（7）开发的技术风险是什么?
（8）考虑过软件需求的其他方案吗?
（9）检验标准详细制定了吗?他们能否确认系统是成功的?
（10）有没有遗漏、重复或者不一致的地方?
（11）与用户或需求者的联系充分吗?
（12）用户复审了初步的用户手册吗?
（13）软件计划中的估算如何受到影响?
3.1 软件需求分析的任务
3.1.1 软件需求分析的目标
▪ 利用软件范围作为指南，软件需求分析试图实现如下几个 目标：
1) 揭示系统信息的流程与结构，为软件的开发打下基础。 2) 确定接口细节、深入描述软件功能、确定设计的约束、
规定软件的检验需求，以此来说明该软件。 3) 建立并保持与用户以及软件需求者的联系，以便实现上9Leabharlann 3.2 软件需求分析的步骤
8
3.2 软件需求分析的步骤
3.2.1 问题的分析
▪ 首先，系统分析员应该仔细研究可行性分析报告和软件项 目实施计划，确定软件的需求，并提出这些需求的实现条 件及应该达到的标准。
▪ 其次， 问题分析是建立分析所需要的通信途径，以保证 顺利地分析问题。
▪ 再次，在问题分析过程中还必须充分重视和使用数据流图、 数据字典和算法描述工具。
（6）设计的限制条件是现实的吗?
（7）开发的技术风险是什么?
（8）考虑过软件需求的其他方案吗?
（9）检验标准详细制定了吗?他们能否确认系统是成功的?
（10）有没有遗漏、重复或者不一致的地方?
（11）与用户或需求者的联系充分吗?
（12）用户复审了初步的用户手册吗?
（13）软件计划中的估算如何受到影响?
3.1 软件需求分析的任务
3.1.1 软件需求分析的目标
▪ 利用软件范围作为指南，软件需求分析试图实现如下几个 目标：
1) 揭示系统信息的流程与结构，为软件的开发打下基础。 2) 确定接口细节、深入描述软件功能、确定设计的约束、
规定软件的检验需求，以此来说明该软件。 3) 建立并保持与用户以及软件需求者的联系，以便实现上9Leabharlann 3.2 软件需求分析的步骤
04、软件需求分析学习课件.ppt
Boehm 给出软件需求的定义：研究一种无二义性 的表达工具，它能为用户和软件人员双方都接受 ，并能够把“需求”严格地、形式地表达出来。
“需求、设计、编程、测试四者究竟哪个环节最 重要？”
➢ 首先，每个环节都是很重要，任何一个环节出现问题 ，都会导致软件的质量问题。
➢ 但是，从管理的角度来看，需求是软件产品的起源， 因而是最重要的一个环节
依据功能需求，性能需求，运行环境需求等，剔 除其不合理的部分，增加其需要部分。最终综合 成系统的解决方案，给出目标系统的详细逻辑模 型。
需求分析是一项必须的软件工程活动。它 在系统需求分析和软件设计之间起到桥梁 的作用：
➢ 它使得软件开发人员在系统分析的基础上深入描述软 件的功能和性能、指明软件和其他系统元素的接口， 建立软件必须满足的约束条件。
➢ 它允许软件开发人员对关键问题进行细化，并构建相 应的分析模型：数据、功能和行为模型。
演示课件
19
4.7.6 用户需求说明书与 软件需求规格说明书的区别
前者主要采用自然语言来表达用户需求，其内容 相对于后者而言比较粗略，不够详细。
后者是前者的细化，更多地采用计算机语言和图 形符号来刻画需求，软件需求是软件系统设计的 直接依据。
两者之间可能并不存在一一影射关系，因为软件 开发商会根据产品发展战略、企业当前状况适当 地调整软件需求，例如用户需求可能被分配到软 件的数个版本中。软件开发人员应当依据《软件 需求规格说明书》来开发当前产品。
➢ 信息结构。
信息结构表示了各种数 据和控制项的内部组织
演示课件
11
4.6.2 功能及行为建模
功能模型：对进入软件的信息和数据进行变换和处理的 模块，它必须至少完成三个常见功能：输入、处理和输 出。
“需求、设计、编程、测试四者究竟哪个环节最 重要？”
➢ 首先，每个环节都是很重要，任何一个环节出现问题 ，都会导致软件的质量问题。
➢ 但是，从管理的角度来看，需求是软件产品的起源， 因而是最重要的一个环节
依据功能需求，性能需求，运行环境需求等，剔 除其不合理的部分，增加其需要部分。最终综合 成系统的解决方案，给出目标系统的详细逻辑模 型。
需求分析是一项必须的软件工程活动。它 在系统需求分析和软件设计之间起到桥梁 的作用：
➢ 它使得软件开发人员在系统分析的基础上深入描述软 件的功能和性能、指明软件和其他系统元素的接口， 建立软件必须满足的约束条件。
➢ 它允许软件开发人员对关键问题进行细化，并构建相 应的分析模型：数据、功能和行为模型。
演示课件
19
4.7.6 用户需求说明书与 软件需求规格说明书的区别
前者主要采用自然语言来表达用户需求，其内容 相对于后者而言比较粗略，不够详细。
后者是前者的细化，更多地采用计算机语言和图 形符号来刻画需求，软件需求是软件系统设计的 直接依据。
两者之间可能并不存在一一影射关系，因为软件 开发商会根据产品发展战略、企业当前状况适当 地调整软件需求，例如用户需求可能被分配到软 件的数个版本中。软件开发人员应当依据《软件 需求规格说明书》来开发当前产品。
➢ 信息结构。
信息结构表示了各种数 据和控制项的内部组织
演示课件
11
4.6.2 功能及行为建模
功能模型：对进入软件的信息和数据进行变换和处理的 模块，它必须至少完成三个常见功能：输入、处理和输 出。
软件需求分析PPT课件
原型设计工具
原型设计工具用于快速创建软件原型， 帮助团队更好地理解用户需求和设计 软件界面。
常见的原型设计工具包括Axure、 Sketch、Figma等，这些工具支持快 速设计和制作高保真原型，方便团队 成员进行讨论和评审。
需求分析建模工具
需求分析建模工具用于对软件需求进行分析、建模和规格编写，帮助团队更好地 理解和规范软件需求。
评审
组织专家或利益相关者对需求规格说 明进行评审，确保内容的准确性和完 整性。
修改
根据评审结果，对需求规格说明进行 修改和完善，确保满足利益相关者的 需求。
需求规格说明的发布与维护
发布
将需求规格说明正式发布给相关人员，确保利益相关者了解和遵循。
维护
在软件开发生命周期中，对需求规格说明进行维护和更新，确保其与实际需求保持一致。
定期对需求变更进行审查，确保变 更得到有效控制。
沟通与协调
及时向相关干系人报告变更情况， 确保信息一致性。
04
06 软件需求分析工具
需求管理工具
需求管理工具用于记录、跟踪和管理 软件需求，确保需求变更得到及时处 理和正确实施。
常见的需求管理工具包括Jira、 MantisBT等，这些工具提供了需求跟 踪、版本控制、变更管理等功能，帮 助团队更好地协作和管理需求。
需求分析的流程
需求整理
对收集到的需求进行分类、筛 选、合并、去重等处理。
需求规格说明
编写需求规格说明书，明确需 求的细节和验收标准。
需求收集
通过访谈、问卷调查、原型演 示等方式收集用户需求。
需求分析
对整理后的需求进行深入分析， 明确系统功能、性能等方面的 具体要求。
需求评审
组织专家或团队对需求规格说 明书进行评审，确保需求的准 确性和完整性。
软件需求管理PPT课件
编写需求规格说明书
将分析和评估后的需求编写成正 式的需求规格说明书，明确软件 系统的功能、性能、非功能需求、 约束和假设条件等。
评审和确认
对编写好的需求规格说明书进行 评审和确认，确保其准确性和完 整性。
需求分析的工具
思维导图工具
如XMind、MindManager等，用于整理和 分析需求。
原型制作工具
初步需求收集
在项目启动阶段进行，主要目的是确定项目的目标和 范围。
深化需求收集
在初步需求收集之后进行，主要目的是细化功能需求 和非功能需求。
变更需求收集
在软件开发过程中进行，主要目的是应对利益相关者 提出的需求变更请求。
03 需求分析
需求分析的目标
确定软件系统的功能和性能 要求。
确定软件系统的约束和假设 条件。
软件需求的重要性
确保开发目标明确
提高软件质量
明确软件的目标和范围，避免开发偏 离方向。
明确的质量要求有助于提高软件的稳 定性和用户体验。
减少返工和变更成本
尽早识别和解决需求问题，降低开发 成本和时间。
软件需求管理过程
01
需求收集
通过与用户沟通、市场调研等方式 获取原始需求。
需求规格说明
编写详细的需求文档，明确各项需 求的细节。
03
为后续的软件开发和测试提供明确的依据。
04
便于需求变更的管理和控制。
需求规格说明的内容
功能需求
包括业务流程、数据流程、界面交互等。
约束和假设条件
如技术限制、开发环境、资源等方面的约束。
非功能需求
包括性能、安全、可用性、可维护性等方面 的要求。
验收标准
用于评估软件是否满足需求的明确标准。
软件工程PPT课件第3章 软件需求分析
5
理
D5 订单表
订单49
1. 数据流图的四个基本成分
2
或
2
数据处理(加工) 数据流（数据对象）
或
II
数据存储 (文件或数据库）
2
或
位于被建模系统之外的信息生 产者或消费者,称为外部项。 说明数据输入的源点(数据源) 或数据输出的汇点(数据池)
50
2. DFD各成分的作用和 命名注意事项
数据流
表示数据和数据流向
抽象出当前系统的逻辑模型
购 书 申 学请
购
生
审查 有效性
书 单
开发票
发 票
开领 书单
领 书 单 发书
书
学 生
学生购买教材的逻辑模型
35
需求分析过程示意
(3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型
无效书单
学 购书单 审查并 发票 领书单 开领
生
开发票
书单
学 生
36
计算机售书系统的逻辑模型
28
(10) 软件成本消耗 与开发进度需求
开发有规定的时间表吗？
软硬件投资有无限制？
29
(11) 质量保证
系统的可靠性要求？
系统必须监测和隔离错误吗？
规定系统平均出错时间？
出错后，重启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？
4
需求分析的任务和步骤
需求分析的任务
建立分析模型 编写需求说明
需求分析的步骤
问题分析
需求描述
需求验证（评审）
5
需求获取的常用方法
《软件需求分析》PPT课件 (2)
2、系统的性能要求
3、系统功能 确定目标系统具备的所有功能
2020/11/28
20
举
例 某学校医疗费管理系统
数据库中存放的是职工的 所属部门、职工号、姓名
职工报销时应填写：
所属部门、职工号、姓名、日期
医疗费分类： 校内门诊、校外门诊、住院费、子女医疗费
该校规定，每年每个职工的医疗费有一个限额（如 80元），限 额在年初确定，其限额规则如下：
23
2、系统性能要求
（1）数据不能随意更改 2）保证数据的准确性 由于医疗费管理系统涉及到会计经费问题，数据不能
随意更改但数据输入又难免会出错。因而在每输入一个职 工的医疗费后，屏幕提示“数据有误吗？”。若是在核对时 有误，可及时更改，避免输入错误。一天报销结束时，在 数据存档前，再让出纳员核对一下经费总额，若出纳员支 出的金额总数有误时，应让计算机显示每笔帐目，供一一 仔细核对，此时在允许修改一次。当正式登帐后，数据就 绝对不允许在修改了，由此保证财务制度的严格性，保证
统计资料：
In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. Thirty-one percent of the software projects were canceled before they were completed. Moreover, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and 16% met those criteria in small companies (Standish 1994).
3、系统功能 确定目标系统具备的所有功能
2020/11/28
20
举
例 某学校医疗费管理系统
数据库中存放的是职工的 所属部门、职工号、姓名
职工报销时应填写：
所属部门、职工号、姓名、日期
医疗费分类： 校内门诊、校外门诊、住院费、子女医疗费
该校规定，每年每个职工的医疗费有一个限额（如 80元），限 额在年初确定，其限额规则如下：
23
2、系统性能要求
（1）数据不能随意更改 2）保证数据的准确性 由于医疗费管理系统涉及到会计经费问题，数据不能
随意更改但数据输入又难免会出错。因而在每输入一个职 工的医疗费后，屏幕提示“数据有误吗？”。若是在核对时 有误，可及时更改，避免输入错误。一天报销结束时，在 数据存档前，再让出纳员核对一下经费总额，若出纳员支 出的金额总数有误时，应让计算机显示每笔帐目，供一一 仔细核对，此时在允许修改一次。当正式登帐后，数据就 绝对不允许在修改了，由此保证财务制度的严格性，保证
统计资料：
In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. Thirty-one percent of the software projects were canceled before they were completed. Moreover, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and 16% met those criteria in small companies (Standish 1994).
《软件需求分析》课件
2
需求分析
对收集到的需求进行分类、分析方法和验证。
3
需求规格说明
编写需求规格文档和需求规格说明书，并满足格式要求。
软件需求分析的工具和技术
用例图和用例描述
通过用例图和用例描述来描 述系统的功能和行为。
数据库图
使用数据库图来描述系统中 的数据结构和关系。
业务流程图
使用业务流程图来描绘系统 的业务流程和工作流程。
系统交互图
使用系统交互图来描述系统与用户或其他系统之 间的交互过程。
其他工具和技术
还有其他一些工具和技术可以用于辅助软件需求 分析，比如原型设计等。
软件需求分析的挑战和解决办法
1 需求不准确
通过与利益相关者密切合作，使用迭代的方 法来不断澄清和明确需求。
2 需求冲突
通过协商和妥协，以及优先级排序等方法来 解决需求之间的冲突。
《软件ቤተ መጻሕፍቲ ባይዱ求分析》PPT课 件
欢迎大家来到本次课程《软件需求分析》的PPT课件。在这个课程中，我们 将会深入探讨软件需求分析的核心内容和使用的工具和技术。
引言
在本节中，我们将介绍什么是软件需求分析、为什么进行软件需求分析以及 软件需求分析的重要性。
软件需求分析流程
1
需求收集
通过收集多渠道的需求来源，并编写需求文档。
3 需求变更
建立灵活的变更管理机制，通过评估和影响 分析来控制需求变更。
4 需求管理
建立完善的需求管理过程和工具，确保需求 的跟踪、审批和变更控制。
总结
通过本次课程，我们了解了软件需求分析的意义、流程、工具和技术，以及面临的挑战和解决办法。
参考资料
书籍 报告 文 网站
软件需求分析-yp共78页PPT资料
例3：如果可能的话，应当根据主货物编号列表在线确认所输入的货物 编号。
修改后： 系统必须根据在线的主货物编号列表确认所输入的货物编号。 如果在主列表中查不到该货物的编号，系统必须显示一个出错消
息并且拒绝订货。
2.4 评审
审查需求文档，由软件开发人员和用户共同完成 依据需求编写测试计划并设计软件测试用例 编写用户手册，用它作为需求规格说明的参考并辅助需求
2.3 编写需求分析文档
好的单个需求陈述应具有：
完整性 正确性 可行性 必要性 划分优先级 无二义性 可验证性 可追溯性 可修改性/可维护性
2.3 编写需求分析文档
需求示例：
例1：产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不 得小于60秒。
软件需求分析
1. 前言 2. 需求分析过程 3. 需求分析原则 4. 需求分析方法 5. 需求分析各方责任
1. 前言
1.1 软件需求的定义 1.2 软件需求的任务 1.3 软件需求的组成 1.4 需求过程的质量对软件开发的影响 1.5 软件需求分析阶段的工作内容
1.1 需求的定义
1. 用户解决问题或达到目标所需的条件或权能。
1.5 需求分析阶段的工作内容
需求工程
需求开发档 评审
2 需求分析过程
用户需求
软件需求分析
软件需求
用户需求规格说明 或
软件开发任务书
软件需求规格说明
2 需求分析过程
问题识别 分析与建模 编写需求分析文档
评审
2 需求分析过程
2.1 问题识别 2.2 分析与建模 2.3 编写需求分析文档 2.4 评审
2.4 评审
组织和完整性
所有对其它需求的内部交叉引用是否正确？ 所有需求的编写在细节上是否都一致或者合适？ 需求是否能为设计提供足够的基础？ 是否包括了每个需求的实现优先级？ 是否定义了所有外部硬件、软件和通信接口？ 是否定义了功能需求的处理模型（计算模型、控制模型
修改后： 系统必须根据在线的主货物编号列表确认所输入的货物编号。 如果在主列表中查不到该货物的编号，系统必须显示一个出错消
息并且拒绝订货。
2.4 评审
审查需求文档，由软件开发人员和用户共同完成 依据需求编写测试计划并设计软件测试用例 编写用户手册，用它作为需求规格说明的参考并辅助需求
2.3 编写需求分析文档
好的单个需求陈述应具有：
完整性 正确性 可行性 必要性 划分优先级 无二义性 可验证性 可追溯性 可修改性/可维护性
2.3 编写需求分析文档
需求示例：
例1：产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不 得小于60秒。
软件需求分析
1. 前言 2. 需求分析过程 3. 需求分析原则 4. 需求分析方法 5. 需求分析各方责任
1. 前言
1.1 软件需求的定义 1.2 软件需求的任务 1.3 软件需求的组成 1.4 需求过程的质量对软件开发的影响 1.5 软件需求分析阶段的工作内容
1.1 需求的定义
1. 用户解决问题或达到目标所需的条件或权能。
1.5 需求分析阶段的工作内容
需求工程
需求开发档 评审
2 需求分析过程
用户需求
软件需求分析
软件需求
用户需求规格说明 或
软件开发任务书
软件需求规格说明
2 需求分析过程
问题识别 分析与建模 编写需求分析文档
评审
2 需求分析过程
2.1 问题识别 2.2 分析与建模 2.3 编写需求分析文档 2.4 评审
2.4 评审
组织和完整性
所有对其它需求的内部交叉引用是否正确？ 所有需求的编写在细节上是否都一致或者合适？ 需求是否能为设计提供足够的基础？ 是否包括了每个需求的实现优先级？ 是否定义了所有外部硬件、软件和通信接口？ 是否定义了功能需求的处理模型（计算模型、控制模型
软件工程第三章 软件需求分析 PPT课件
购 书 申 学 请 书 购 单 开发票 发 票 领 书 单 发书
生
审查 有效性
开领 书单
书
学 生
学生购买教材的逻辑模型
需求分析过程示意
(3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型
无效书单
学 购书单 审查并 发票 领书单 开领
生
开发票
书单
学 生
计算机售书系统的逻辑模型
需求分析过程示意
对象 系统
抽象（映射） 模型应用
模型 系统
模型构造的过程
逻辑模型 (本质模型、概念模型)
物理模型 (实施模型、技术模型)
现 行 系 统
描述重要的业务 功能，无论系统 是如何实施的。
描述现实系统是 如何在物理上实 现的。 描述新系统是如 何实施的（包括 技术）。
目 标 系 统
描述新系统的主要 业务功能和用户新 的需求，无论系统 应如何实施。
接收、发送数据的频率？
数据的准确性和精度？ 数据流量？ 数据需保持的时间？
(8)
资源需求
软件运行时所需的数据、软件。
内存空间等资源。
软件开发、维护所需的人力、
支撑软件、开发设备等。
(9)
安全保密要求
需对访问系统或系统信息
加以控制吗？ 如何隔离用户之间的数据？ 用户程序如何与其它程序 和操作系统隔离？ 系统备份要求？
(1)
功能需求
系统做什么？
系统何时做什么？
系统何时及如何修改
或升级？
(2)
性能需求
软件开发的技术性指标：
存储容量限制 执行速度、相应时间 吞吐量
(3)
环境需求
生
审查 有效性
开领 书单
书
学 生
学生购买教材的逻辑模型
需求分析过程示意
(3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型
无效书单
学 购书单 审查并 发票 领书单 开领
生
开发票
书单
学 生
计算机售书系统的逻辑模型
需求分析过程示意
对象 系统
抽象（映射） 模型应用
模型 系统
模型构造的过程
逻辑模型 (本质模型、概念模型)
物理模型 (实施模型、技术模型)
现 行 系 统
描述重要的业务 功能，无论系统 是如何实施的。
描述现实系统是 如何在物理上实 现的。 描述新系统是如 何实施的（包括 技术）。
目 标 系 统
描述新系统的主要 业务功能和用户新 的需求，无论系统 应如何实施。
接收、发送数据的频率？
数据的准确性和精度？ 数据流量？ 数据需保持的时间？
(8)
资源需求
软件运行时所需的数据、软件。
内存空间等资源。
软件开发、维护所需的人力、
支撑软件、开发设备等。
(9)
安全保密要求
需对访问系统或系统信息
加以控制吗？ 如何隔离用户之间的数据？ 用户程序如何与其它程序 和操作系统隔离？ 系统备份要求？
(1)
功能需求
系统做什么？
系统何时做什么？
系统何时及如何修改
或升级？
(2)
性能需求
软件开发的技术性指标：
存储容量限制 执行速度、相应时间 吞吐量
(3)
环境需求
软件工程需求分析需求分析PPT课件
• 小组负责人要求每位参加者列出问题及环境中的有 关对象，对这些对象施行的操作以及对象间的相互 作用。列出的操作和对象尽可能完全，如，控制面 板、电话机、监控中心、烟雾传感器、门窗监视器、 警报器等对象，以及用户编程控制、电话拔号、报 警等操作。
• 负责人应要求小组成员对接收传感器事件、用户编 程控制、电话报警等操作进行更详细的描述，必要 时可用流程图表示。
• 细化数据流图（DFD），必要时，对实时系统还要 绘制控制流图（CFD）；
• 编制数据字典；
2020/7/31
19
5.1.4 需求分析的活动和原则
• 活动主要分为： – 需求获取； – 分析建模； – 需求评审
2020/7/31
20
需求获取的目标
• 对用户需求进行鉴别、综合，清除用户需求的 模糊性、歧义性和不一致性；
• 把对原始问题的理解和软件开发经验结合起来， 鉴别由于用户的片面性或短期行为所导致的不 合理要求，发现用户尚未发现的但具有真正价 值的潜在需求；
2020/7/31
28
家庭保安系统
分析初期联合小组的工作程序
联合小组首先制定工作制度：每次会议开始 前必须有确定的议程，参加者必须针对各项议程 进行充分的准备，并用文字表示。
经过会议讨论，明确问题的范围、问题与环 境的关系，并就开发软件产品的必要性达成共识。
2020/7/31
29
例 家庭保安系统
• 这个计划到综合测试后期执行。
2020/7/31
8
3. 修订开发计划
• 系统调查与可行性研究阶段的最后，草拟了初步 的开发计划，当时由于需求尚不详细，现可有了 详细的需求分析结果以后，应该使开发计划更准 确一些。
2020/7/31
• 负责人应要求小组成员对接收传感器事件、用户编 程控制、电话报警等操作进行更详细的描述，必要 时可用流程图表示。
• 细化数据流图（DFD），必要时，对实时系统还要 绘制控制流图（CFD）；
• 编制数据字典；
2020/7/31
19
5.1.4 需求分析的活动和原则
• 活动主要分为： – 需求获取； – 分析建模； – 需求评审
2020/7/31
20
需求获取的目标
• 对用户需求进行鉴别、综合，清除用户需求的 模糊性、歧义性和不一致性；
• 把对原始问题的理解和软件开发经验结合起来， 鉴别由于用户的片面性或短期行为所导致的不 合理要求，发现用户尚未发现的但具有真正价 值的潜在需求；
2020/7/31
28
家庭保安系统
分析初期联合小组的工作程序
联合小组首先制定工作制度：每次会议开始 前必须有确定的议程，参加者必须针对各项议程 进行充分的准备，并用文字表示。
经过会议讨论，明确问题的范围、问题与环 境的关系，并就开发软件产品的必要性达成共识。
2020/7/31
29
例 家庭保安系统
• 这个计划到综合测试后期执行。
2020/7/31
8
3. 修订开发计划
• 系统调查与可行性研究阶段的最后，草拟了初步 的开发计划，当时由于需求尚不详细，现可有了 详细的需求分析结果以后，应该使开发计划更准 确一些。
2020/7/31
《软件需求分析》需求管理ppt课件
…Task.Step.Substep
版本控制
每一条单独的需求需要进行版本控制 相关的需求文档也需要进行版本控制
变更控制 访问审计
记录和审计访问的情况
状态报告
反映需求基线的成熟度（变化的幅度越大，成熟度越低）、稳定性（改变 的次数越多，稳定性越差）等
2. 需求基线 ——维护活动：状态维护
需求管理
在需求开发之后的产品生命周期当中保证需求作用 的有效发挥
1. 需求管理 ——作用
增强了项目涉众对复杂产品特征在细节和相互依赖关系上 的理解
增强了项目涉众对需求（尤其是复杂需求）的掌握。
增进了项目涉众之间的交流
减少了可能的误解和交流偏差。
减少了工作量的浪费，提高了生产力
向前跟踪到需求：说明涉众的需要和目标产生了哪些软件需求 从需求向后回溯：说明软件需求来源于哪些涉众的需要和目标
后向跟踪是指被定义到软件需求规格说明文档之后的需求 演化过程
从需求向前跟踪：说明软件需求是如何被后续的开发物件支持和实现的 回溯到需求的跟踪：说明各种系统开发的物件是因为什么原因（软件需求）
状态
定义
已提议（Proposed）该需求已被有相应权限的人提出
已批准（Approved）该需求已经被分析，它对项目的影响已进行了估计，并且
已经被分配到某一特定版本的基线中。关键涉众已同意包
含这一需求，软件开发团队已承诺实现这一需求
已 实 现 实现这一需求的系统组件已经完成了设计和实现。这一需 （Implemented） 求已经被跟踪到相关的设计元素和实现元素
共同的需求理解 纳入配置管理的文档 变更控制
2. 需求基线 ——描述内容
标识符（ID），为后续的项目工作提供一个共同的交流参照。 当前版本号（Version），保证项目的各项工作都建立在最新的一致需求基础
版本控制
每一条单独的需求需要进行版本控制 相关的需求文档也需要进行版本控制
变更控制 访问审计
记录和审计访问的情况
状态报告
反映需求基线的成熟度（变化的幅度越大，成熟度越低）、稳定性（改变 的次数越多，稳定性越差）等
2. 需求基线 ——维护活动：状态维护
需求管理
在需求开发之后的产品生命周期当中保证需求作用 的有效发挥
1. 需求管理 ——作用
增强了项目涉众对复杂产品特征在细节和相互依赖关系上 的理解
增强了项目涉众对需求（尤其是复杂需求）的掌握。
增进了项目涉众之间的交流
减少了可能的误解和交流偏差。
减少了工作量的浪费，提高了生产力
向前跟踪到需求：说明涉众的需要和目标产生了哪些软件需求 从需求向后回溯：说明软件需求来源于哪些涉众的需要和目标
后向跟踪是指被定义到软件需求规格说明文档之后的需求 演化过程
从需求向前跟踪：说明软件需求是如何被后续的开发物件支持和实现的 回溯到需求的跟踪：说明各种系统开发的物件是因为什么原因（软件需求）
状态
定义
已提议（Proposed）该需求已被有相应权限的人提出
已批准（Approved）该需求已经被分析，它对项目的影响已进行了估计，并且
已经被分配到某一特定版本的基线中。关键涉众已同意包
含这一需求，软件开发团队已承诺实现这一需求
已 实 现 实现这一需求的系统组件已经完成了设计和实现。这一需 （Implemented） 求已经被跟踪到相关的设计元素和实现元素
共同的需求理解 纳入配置管理的文档 变更控制
2. 需求基线 ——描述内容
标识符（ID），为后续的项目工作提供一个共同的交流参照。 当前版本号（Version），保证项目的各项工作都建立在最新的一致需求基础
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
.
11
主要内容
1. 需求管理 2. 需求基线 3. 需求跟踪 4. 需求变更控制 5. 需求管理的实践调查
.
12
3. 需求跟踪
避免在开发过程或者演化过程中与需求基线不一致或者偏 离的风险
涉众需要/目标
跟踪 回溯
软件需求 （软件需求规格说明文档）
跟踪 回溯
后续开发物件
前向跟踪是指被定义到软件需求规格说明文档之前的需求 演化过程
需求管理
在需求开发之后的产品生命周期当中保证需求作用 的有效发挥
.
3
1. 需求管理 ——作用
增强了项目涉众对复杂产品特征在细节和相互依赖关系上 的理解
增强了项目涉众对需求（尤其是复杂需求）的掌握。
增进了项目涉众之间的交流
减少了可能的误解和交流偏差。
减少了工作量的浪费，提高了生产力
需求管理能够更加有效的处理需求的变更
共同的需求理解 纳入配置管理的文档 变更控制
.
8
2. 需求基线
——描述内容
标识符（ID），为后续的项目工作提供一个共同的交流参照。
当前版本号（Version），保证项目的各项工作都建立在最新的一致需求基础 之上。
源头（Source），在需要进一步深入理解或者改变需求时，可以回溯到需求 的源头。
理由（Rational），提供需求产生的背景知识。
优先级（Priority），后续的项目工作可以参照优先级进行安排和调度。
状态（Status），交流和具体需求相关的项目工作状况。
成本、工作量、风险、可变性（Cost、Effort、Risk、Volatility），为需求的 设计和实现提供参考信息，驱动设计和实现工作。
已验证（Verified）已在集成产品中确认了这一需求的功能实现是正确的。这 一需求已经被跟踪到相关的测试用例。这一需求目前可以 被认为是已完成了
已 删 除 （ Deleted）已批准的需求又从需求基线中取消了。要解释清楚为什么 要删除这一需求，以及是谁决定删除的
已否决（Rejected）需求已被提议，但并不在下一版本中实现它。要解释清楚 为什么要否决这一需求，以及是谁决定否决的
需求创建的日期；
和需求相关的项目工作人员，包括需求的作者、设计者、实现者、测试者等；
需求涉及的子系统；
需求涉及的产品版本号；
需求的验收和验证标准；
…
.
9
2. 需求基线 ——维护活动：配置管理
标识配置项
递增数值，例如1，2，…x； 层次式数值编码，例如1.1.1，1.2.1，…x.y.z； 层次式命名编码，例如Order.Place.Date，
而被开发出来的
.
13
3. 需求跟踪 ——用途（1）
需求的后向跟踪可以帮助项目管理者：
评估需求变更的影响； 尽早发现需求之间的冲突，避免未预料的产品延期； 可以收集没有被实现的需求，并估算这些需求需要的工作量； 发现可以复用的已有组件，从而降低新系统开发的时间和精力； 明确需求的实现进度，跟踪项目的状态。
.
7
需求基线
已经通过正式评审和批准的规格说明或产品，它 可以作为进一步开发的基础，并且只有通过正式 的变更控制过程才能修改它
是被明确和固定下来的需求集合，是项目团队需 要在某一特定产品版本中实现的特征和需求集合
需求开发 建立需求基线 需求管理
不同的需求看法 没有正式文档 总是处于变化之中
准确反映项目的状态，帮助进行更好的项目决策
需求跟踪信息能够更加准确的反映项目的进展情况
改变项目文化，使得需求的作用得到重视和有效发挥
使得项目涉众认识到需求在项目工作中的重要性
.
4
1. 需求管理 ——任务
交流涉众需要什么； 将需求应用、实施到解决方案； 驱动设计和实现工作； 控制变更； 将需求分配到子系统； 测试和验证最终产品； 控制迭代式开发中的变化； 辅助项目管理
向前跟踪到需求：说明涉众的需要和目标产生了哪些软件需求
从需求向后回溯：说明软件需求来源于哪些涉众的需要和目标
后向跟踪是指被定义到软件需求规格说明文档之后的需求 演化过程
从需求向前跟踪：说明软件需求是如何被后续的开发物件支持和实现的 回溯到需求的跟踪：说明各种系统开发的物件是因为什么原因（软件需求）
第17章.需求管理
.
1
主要内容
1. 需求管理 2. 需求基线 3. 需求跟踪 4. 需求变更控制 5. 需求管理的实践调查
.
2
1. 需求管理 ——意图
需求的影响力
整个后续的产品生命周期 VS 需求开发阶段
需求规格说明文档
后续的开发工作都应该以软件需求规格说明文档的 内容为标准和目标来进行
Order.Place.Register，…Task.Step.Substep
版本控制
每一条单独的需求需要进行版本控制 相关的需求文档也需要进行版本控制
变更控制 访问审计
记录和审计访问的情况
状态报告
反映需求基线的成熟度（变化的幅度越大，成熟度越低）、稳定性（改变 的次数越多，稳定性越差）等
需求的后向跟踪可以帮助客户和用户：
评价针对用户需求的产品的质量； 可以确认成本上没有（昂贵的）镀金浪费； 确认验收测试的有效性； 确信开发者的关注点始终保持在需求的实现上。
.
14
3. 需求跟踪 ——用途（2）
需求跟踪中针对具体需求的设计方案选择、设计假设条件 以及设计结果等信息可以帮助设计人员：
.
5
1. 需求管理 ——活动
需求管理
维护需求基线
交流涉众需要什么 驱动设计和实现工作 测试和验证最终产品 辅助项目管理
实现需求跟踪
控制变更
将需求应用到解决方案 将需求分配到子系统
控制变更 控制迭代式开发中的变化
.
6
主要内容
1. 需求管理 2. 需求基线 3. 需求跟踪 4. 需求变更控制 5. 需求管理的实践调查
.
10
2. 需求基线 ——维护活动：状态维护
状态
定义
已提议（Proposed）该需求已被有相应权限的人提出
已批准（Approved）该需求已经被分析，它对项目的影响已进行了估计，并且
已经被分配到某一特定版本的基线中。关键涉众已同意包
含这一需求，软件开发团队已承诺实现这一需求
已 实 现 实现这一需求的系统组件已经完成了设计和实现。这一需 （Implemented） 求已经被跟踪到相关的设计元素和实现元素