软件工程课件学习3
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• AIRMICS所进行的一项调查发现，在一份 美国军方大型管理信息系统的需求现格说 明书(SRS)中存在着500多个错误，当然这 仅仅是一个软件项目中的一次调查。
h
6
需求分析的重要性
– 在需求阶段，代表性的错误为疏忽、不一致和 二义性
• 美国海军研究实验室从20世纪70年代起就对
软件开发技术不断地进行研究。他们对海军 A—7E—它机上的”宅行操作程序进行实地 测试，以验证许多新设想的可行性。得出的 研究数据表明：A—7E项目中77％的需求错
13.1% 不完整的产品要求； 12.4% 缺乏用户的参与； 10.6% 缺少资源（人力、财力）； 9.9% 不现实的期望； 9.3% 高层领导支持不足； 8.7% 产品要求与指标的改变； 8.1% 没有订计划； 7.5% 不再需耍该开发中的系统。 其中，与产品需求有关的（1,2,4,和6项）占了44.1%。这些 数据突出地显示了软件产品需求在软件开发中的重要性。
（3）一种反映上面（1）或（2）所描 述的条件或能力的文档说明。
h
11
需求分析
需求分析
困难：
片面性, 不完全
模糊性, 不准确 不一致性, 歧义等等 应用系统复杂，庞大
因此必须使用系统的方法、借助于一系列行之 有效的技术和工具进行需求分析
h
12
按层次划分软件需求
• 业务需求( business requirement)反映Fra Baidu bibliotek组织机构或客户对系 统、产品高层次的目标要求，它们在项目视图与范围文档中 予以说明。业务需求描述了企业一组概要性的目标，概要性 的目标可能要依靠多个用户目标来实现。
非功能需求
过程需求
产品需求
外部需求
软件交付
实现方法
标准
互操作性
法规
成本
可用性
可移植性
软件性能
安全性 h
存储空间
可靠性 15
2.1 软件需求的概念
软件需求分析的困难
(1)客户说不清楚需求 • 有些客户对需求只有朦胧的感觉，当然说不清楚具体
的需求。
农夫和耕牛的故事
• 有些客户心里非常清楚想要什么，但却说不明白。
误特点是不明确：疏忽、不一致和二义性。
按错误类型对这些错误分布进行分析的结果 是：
• 49％不正确的事实，31％疏忽，l 3％不一致
，5％二义性
h
7
需求分析的重要性
– 需求错误是可以被检查出来的
h
8
参与需求分析的人有哪些，场所在哪
• 参与需求分析的人
– 系统分析师、需求阐释者、客户代表、用户代表 、开发方领导、项目经理、架构设计师、领域专 家、财务人员、市场人员、软件质量保证（SQA ，Software Quality Assure）人员、程序员、测试 人员、部署人员、技术文档编写人员、培训人员 等。
• 用户需求(user requirement) 文档描述了用户使用产品必须 要完成的任务，这在使用实例(use case)文档或方案脚本 (scenario)说明中予以说明。用户需求描述了用户目标，是 具体明确的任务，但还不是详细的细节。
• 功能需求(functional requirement)定义了开发人员必须实现
h
2.1 软件需求的概念
个人能力或经验不足。 软件组织的能力不足
18
§1. 需求分析的任务
§1. 需求分析的任务
1、确定要求
(1)功能要求
(5)接口需求
(2)性能要求
(6)约束
(3)可靠性和可用性需求 (7)逆向需求
• 需求分析的场所
– 调研时，在客户现场
– 编纂软件需求规约文档时，可以在开发单位
– 复审相关的需求文档时h ，根据需要来安排 9
h
10
第3章 需求分析
需求分析
IEEE软件工程标准词汇表将需求定义为： （1）用户解决问题或达到目标所需的
条件或能力。 （2）系统或系统部件要满足合同、标
准、规范或其它正式规定文档所需具有的条 件或能力。
软件工程
---第3章 需求分析
h
1
软件需求分析：“做什么？”
需求分析的过程是开发人员与用 户共同协商，准确地定义未来系统的 目标，确定为了满足用户的需求系统 必须做什么。并且使用软件开发人员 和用户都能理解的语言准确地表达出 来，即用 <需求规格说明书> 规范的
形式准确地表达用户的需求。
h
2
需求分析
第3章 需求分析
开发一个软件系统前，必须了解用户的期望 和要求---> 软件需求 ---> 需求分析过程
重要性：
软件开发的基础和前提 最终目标软件系统验收的标准 避免或者尽早剔除早期的错误
h
3
需求的重要性
Standish-Group对350家公司的8000个软件项目作过一次调查 其中，31%的项目的结局是被取消。 引致这些项目失败的原因是：
h
客户的能力不足，可以进行 适当的培训，可改善一点。
属于态度问题，需要高层领导 协调。
不可避免。只能通过合同约 束或有限度接受，或通过技 术提高软件适应能力。
17
软件需求的复杂性
(2)需求自身经常变动
需求变更原因—软件人员： 沟通技巧不高 需求工程技术不精 需求人员知识储备不够 不了解客户方的业务流程 调研范围不确定 需求不够细致、明确 项目管理不规范 需求描述存在歧义 合同对客户方约束不够
h
4
需求分析的重要性
• 5点事实
– 软件生命周期中，一个错误发现得越晚，修 复错误的费用越高
2020/10/16
h
5
需求分析的重要性
– 许多错误是潜伏的，并且在错误产生后很长一 段时间才被检查出来
– 在需求过程中会产生很多错误
• DeMarco在一份研究报告中指出，被检查 出来的错误的56％产生的根源可以追溯到 需求阶段。
我的鞋是什么样的？
• “不懂装懂”或者“半懂充内行”的客户令人恐惧
h
16
软件需求的复杂性
(2)需求自身经常变动
2.1 软件需求的概念
需求变更原因--客户方： 对信息系统的了解不够 对业务需求表达不清 对自身业务抽象程度不够
对需求重视程度不够 与开发人员配合不够
业务范围不断拓展
业务流程不断变更
管理模式不断创新
的软件功能，使得用户能完成他们的任务，从而满足了业务
需求。
h
13
三类需求的关系
概要目标层次
业务需求
项目视图与范围文档
用户目标层次
用户需求
使用实例文档
功能层次
功能需求
非功能 需求
软件需求规格说明书
h
14
软件需求的非功能性需求
• 非功能需求:定义产品必须遵从的标准、规范 和合约；外部界面的具体细节；性能要求； 设计或实现的约束条件及质量属性。
h
6
需求分析的重要性
– 在需求阶段，代表性的错误为疏忽、不一致和 二义性
• 美国海军研究实验室从20世纪70年代起就对
软件开发技术不断地进行研究。他们对海军 A—7E—它机上的”宅行操作程序进行实地 测试，以验证许多新设想的可行性。得出的 研究数据表明：A—7E项目中77％的需求错
13.1% 不完整的产品要求； 12.4% 缺乏用户的参与； 10.6% 缺少资源（人力、财力）； 9.9% 不现实的期望； 9.3% 高层领导支持不足； 8.7% 产品要求与指标的改变； 8.1% 没有订计划； 7.5% 不再需耍该开发中的系统。 其中，与产品需求有关的（1,2,4,和6项）占了44.1%。这些 数据突出地显示了软件产品需求在软件开发中的重要性。
（3）一种反映上面（1）或（2）所描 述的条件或能力的文档说明。
h
11
需求分析
需求分析
困难：
片面性, 不完全
模糊性, 不准确 不一致性, 歧义等等 应用系统复杂，庞大
因此必须使用系统的方法、借助于一系列行之 有效的技术和工具进行需求分析
h
12
按层次划分软件需求
• 业务需求( business requirement)反映Fra Baidu bibliotek组织机构或客户对系 统、产品高层次的目标要求，它们在项目视图与范围文档中 予以说明。业务需求描述了企业一组概要性的目标，概要性 的目标可能要依靠多个用户目标来实现。
非功能需求
过程需求
产品需求
外部需求
软件交付
实现方法
标准
互操作性
法规
成本
可用性
可移植性
软件性能
安全性 h
存储空间
可靠性 15
2.1 软件需求的概念
软件需求分析的困难
(1)客户说不清楚需求 • 有些客户对需求只有朦胧的感觉，当然说不清楚具体
的需求。
农夫和耕牛的故事
• 有些客户心里非常清楚想要什么，但却说不明白。
误特点是不明确：疏忽、不一致和二义性。
按错误类型对这些错误分布进行分析的结果 是：
• 49％不正确的事实，31％疏忽，l 3％不一致
，5％二义性
h
7
需求分析的重要性
– 需求错误是可以被检查出来的
h
8
参与需求分析的人有哪些，场所在哪
• 参与需求分析的人
– 系统分析师、需求阐释者、客户代表、用户代表 、开发方领导、项目经理、架构设计师、领域专 家、财务人员、市场人员、软件质量保证（SQA ，Software Quality Assure）人员、程序员、测试 人员、部署人员、技术文档编写人员、培训人员 等。
• 用户需求(user requirement) 文档描述了用户使用产品必须 要完成的任务，这在使用实例(use case)文档或方案脚本 (scenario)说明中予以说明。用户需求描述了用户目标，是 具体明确的任务，但还不是详细的细节。
• 功能需求(functional requirement)定义了开发人员必须实现
h
2.1 软件需求的概念
个人能力或经验不足。 软件组织的能力不足
18
§1. 需求分析的任务
§1. 需求分析的任务
1、确定要求
(1)功能要求
(5)接口需求
(2)性能要求
(6)约束
(3)可靠性和可用性需求 (7)逆向需求
• 需求分析的场所
– 调研时，在客户现场
– 编纂软件需求规约文档时，可以在开发单位
– 复审相关的需求文档时h ，根据需要来安排 9
h
10
第3章 需求分析
需求分析
IEEE软件工程标准词汇表将需求定义为： （1）用户解决问题或达到目标所需的
条件或能力。 （2）系统或系统部件要满足合同、标
准、规范或其它正式规定文档所需具有的条 件或能力。
软件工程
---第3章 需求分析
h
1
软件需求分析：“做什么？”
需求分析的过程是开发人员与用 户共同协商，准确地定义未来系统的 目标，确定为了满足用户的需求系统 必须做什么。并且使用软件开发人员 和用户都能理解的语言准确地表达出 来，即用 <需求规格说明书> 规范的
形式准确地表达用户的需求。
h
2
需求分析
第3章 需求分析
开发一个软件系统前，必须了解用户的期望 和要求---> 软件需求 ---> 需求分析过程
重要性：
软件开发的基础和前提 最终目标软件系统验收的标准 避免或者尽早剔除早期的错误
h
3
需求的重要性
Standish-Group对350家公司的8000个软件项目作过一次调查 其中，31%的项目的结局是被取消。 引致这些项目失败的原因是：
h
客户的能力不足，可以进行 适当的培训，可改善一点。
属于态度问题，需要高层领导 协调。
不可避免。只能通过合同约 束或有限度接受，或通过技 术提高软件适应能力。
17
软件需求的复杂性
(2)需求自身经常变动
需求变更原因—软件人员： 沟通技巧不高 需求工程技术不精 需求人员知识储备不够 不了解客户方的业务流程 调研范围不确定 需求不够细致、明确 项目管理不规范 需求描述存在歧义 合同对客户方约束不够
h
4
需求分析的重要性
• 5点事实
– 软件生命周期中，一个错误发现得越晚，修 复错误的费用越高
2020/10/16
h
5
需求分析的重要性
– 许多错误是潜伏的，并且在错误产生后很长一 段时间才被检查出来
– 在需求过程中会产生很多错误
• DeMarco在一份研究报告中指出，被检查 出来的错误的56％产生的根源可以追溯到 需求阶段。
我的鞋是什么样的？
• “不懂装懂”或者“半懂充内行”的客户令人恐惧
h
16
软件需求的复杂性
(2)需求自身经常变动
2.1 软件需求的概念
需求变更原因--客户方： 对信息系统的了解不够 对业务需求表达不清 对自身业务抽象程度不够
对需求重视程度不够 与开发人员配合不够
业务范围不断拓展
业务流程不断变更
管理模式不断创新
的软件功能，使得用户能完成他们的任务，从而满足了业务
需求。
h
13
三类需求的关系
概要目标层次
业务需求
项目视图与范围文档
用户目标层次
用户需求
使用实例文档
功能层次
功能需求
非功能 需求
软件需求规格说明书
h
14
软件需求的非功能性需求
• 非功能需求:定义产品必须遵从的标准、规范 和合约；外部界面的具体细节；性能要求； 设计或实现的约束条件及质量属性。