软件需求获取与结构化分析方法讲解
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 客户表达的需求，不同的分析人员可能有不 同的理解。适当时候有必要快速构造软件的 原型。
12
13
项目失败的原因分析
No.
Top 10 Factors
1
Inadequate requirements specification
不充分的需求规范
2
Changes in requirements 需求的改变
第3章 软件需求获取与结构化分析方法
• 需求获取与需求分析阶段的任务 • 结构化分析方法 • 系统需求规格说明 • 需求评审 • 需求管理
3.1 需求获取与需求分析阶段的任务
• 需求获取的任务和原则 • 需求获取的过程 • 软件需求分析阶段的任务
需求获取的任务和原则
• 需求获取的主要任务是与客户或用户沟通，了解 系统或产品的目标是什么？客户或用户想要实现 什么？系统和产品如何满足业务的要求，最终系 统或产品如何用于日常工作？
• 如说买鞋子。我们非常了解自已的脚，但 没法说清楚脚的大小和形状。只能拿鞋子 去试，试穿时感觉到舒服才会买鞋。
8
客户说不清楚需求
• 如果客户本身就懂软件开发，能把需求说 得清清楚楚，这样的需求分析将会非常轻 松、愉快。
• 如果客户全不懂软件，但信任软件开发方。 则分析人员可以引导客户，先阐述常规的 需求，再由客户否定不需要的，最终确定 客户真正的需求。
• 下雨天留人天留人不留 – 下雨天留人，天留人不留。（不留） – 下雨天，留人天，留人不？留！（留）
11
分析人员或客户理解有误
• 有一个软件人员滔滔不绝地向客户讲解在 “信息高速公路上做广告”的种种好处，客 户听得津津有味。最后，心动的客户对软件 人员说：“好得很，就让我们马上行动起来 吧。请您决定广告牌的尺寸和放在哪条高速 公路上，我立即派人去做。”
需求获取的任务和原则
• “需求会变动”是事实，在进行需求分析时就要留神： • （1）分析清楚哪些是稳定的需求，哪些是易变的需求。
将软件的核心建筑在稳定的需求上。 • （2）在合同中一定要说清楚“做什么”和“不做什么”。
如果合同含含糊糊，日后扯皮的事情就多。
10
分析人员或客户理解有误
• 有个外星人间谍潜伏到地球刺探情报，它给 上司写了一份报告：“主宰地球的是车。它 们喝汽油，靠四个轮子滚动前进。嗓门极大， 在夜里双眼能射出强光。……有趣的是，车 里住着一种叫作‘人’的寄生虫，这些寄生 虫完全控制了车。”
3.8
3.6 3.6
需求获取的任务和原则
1. 需求获取的任务
(1) 发现和分析问题，并分析问题的原因/结果关系。 (2) 与用户进行各种方式的交流，并使用调查研究
方法收集信息。 (3) 按照三个成分观察问题的不同侧面：即数据、
过程和接口。 (4) 将获取的需求文档化，形式有用例、决策表、
需求表等。
• 若是“不懂装懂”或者“半懂充内行”的 客户，他们可能会提出不切实际的需求， 那么沟通和协商都会很困难。
9
需求自身经常变动
• Marshall P. Cline, Greg A. Lomow, C++ FAQs, Addison-Wesley, 1995 记载：没有一个软件的需求改动 少于三次。唯一只改动需求两次的客户是个死人。这个可 怜的家伙还是在运送第三次需求的路上被车子撞死的。
3
Shortage of systems engineers 缺乏系统工程师
4
Shortage of software managers
缺乏了解软件特性的经理人
5
Shortage of qualified project managers
缺乏合格的项目经理
6
Shortage of software engineers
5
为什么需求很重要？
• 需求错误的代价可能会很高昂。 • Boehm和Papaccio报告，如果在需求定义过程中
找出并修复一个基于需求的问题只需花费1美元， 那么，在设计过程中做这些工作就要花费5美元， 在编码过程中就要花费10美元，在单元测试过程 中就要花费20美元，而在系统交付后要花费200 美元之多！ • 因此，花时间理解问题及其背景，然后在第一时 间内修复需求，这样做是值得的。
缺乏软件工程师
Leabharlann Baidu
7
Fixed - price contract 固定价合同
Inadequate communications for system integration 8
系统集成阶段 , 交流与沟通不充分
9
Insufficient experience as team 团队缺乏经验
10 Shortage of application domain experts
6
需求获取的任务和原则
• 导出需求变得如此困难的原因归为以下几 个方面的问题：
➢ 系统的目标或范围问题； ➢ 需求不准确性问题 ； ➢ 需求的易变问题 ；
需求获取除了需要有专业的系统分析师，还需要 通过有效的客户／开发者的合作才能成功。
客户说不清楚需求
• 有些客户心里非常清楚想要什么，但却说 不明白。
4
为什么需求很重要？
• Standish请求被调查者解释项目失败的原因： • 不完整的需求（13.1%） • 缺少用户的参与（12.4%） • 缺乏资源（10.6%） • 不切实际的期望（9.9%） • 缺乏行政支持（9.3%） • 改变需求和规格说明（8.7%） • 缺乏计划（8.1%） • 不再需要该系统（7.5%）
• 获取并理解用户的需求是软件工程师所面对的最 困难的任务之一。
为什么需求很重要？
• 1994年，Standish Group调查了350多家 公司的8000多个软件项目，了解它们的进 展情况。调查结果让人吃惊，31%的软件 项目在完成之前就取消了。另外，在大公 司中，只有9%的项目按时在预算内交付， 而在小公司中，满足这些标准的有16%。
缺乏应用领域专家
Scale: 5 = Very Serious 3 = Serious 1 = No Serious
Source: Carnegie-Mellon University, Software Engineering Institute
平均值
4.5 4.3 4.2 4.1 4.1 3.9 3.8
12
13
项目失败的原因分析
No.
Top 10 Factors
1
Inadequate requirements specification
不充分的需求规范
2
Changes in requirements 需求的改变
第3章 软件需求获取与结构化分析方法
• 需求获取与需求分析阶段的任务 • 结构化分析方法 • 系统需求规格说明 • 需求评审 • 需求管理
3.1 需求获取与需求分析阶段的任务
• 需求获取的任务和原则 • 需求获取的过程 • 软件需求分析阶段的任务
需求获取的任务和原则
• 需求获取的主要任务是与客户或用户沟通，了解 系统或产品的目标是什么？客户或用户想要实现 什么？系统和产品如何满足业务的要求，最终系 统或产品如何用于日常工作？
• 如说买鞋子。我们非常了解自已的脚，但 没法说清楚脚的大小和形状。只能拿鞋子 去试，试穿时感觉到舒服才会买鞋。
8
客户说不清楚需求
• 如果客户本身就懂软件开发，能把需求说 得清清楚楚，这样的需求分析将会非常轻 松、愉快。
• 如果客户全不懂软件，但信任软件开发方。 则分析人员可以引导客户，先阐述常规的 需求，再由客户否定不需要的，最终确定 客户真正的需求。
• 下雨天留人天留人不留 – 下雨天留人，天留人不留。（不留） – 下雨天，留人天，留人不？留！（留）
11
分析人员或客户理解有误
• 有一个软件人员滔滔不绝地向客户讲解在 “信息高速公路上做广告”的种种好处，客 户听得津津有味。最后，心动的客户对软件 人员说：“好得很，就让我们马上行动起来 吧。请您决定广告牌的尺寸和放在哪条高速 公路上，我立即派人去做。”
需求获取的任务和原则
• “需求会变动”是事实，在进行需求分析时就要留神： • （1）分析清楚哪些是稳定的需求，哪些是易变的需求。
将软件的核心建筑在稳定的需求上。 • （2）在合同中一定要说清楚“做什么”和“不做什么”。
如果合同含含糊糊，日后扯皮的事情就多。
10
分析人员或客户理解有误
• 有个外星人间谍潜伏到地球刺探情报，它给 上司写了一份报告：“主宰地球的是车。它 们喝汽油，靠四个轮子滚动前进。嗓门极大， 在夜里双眼能射出强光。……有趣的是，车 里住着一种叫作‘人’的寄生虫，这些寄生 虫完全控制了车。”
3.8
3.6 3.6
需求获取的任务和原则
1. 需求获取的任务
(1) 发现和分析问题，并分析问题的原因/结果关系。 (2) 与用户进行各种方式的交流，并使用调查研究
方法收集信息。 (3) 按照三个成分观察问题的不同侧面：即数据、
过程和接口。 (4) 将获取的需求文档化，形式有用例、决策表、
需求表等。
• 若是“不懂装懂”或者“半懂充内行”的 客户，他们可能会提出不切实际的需求， 那么沟通和协商都会很困难。
9
需求自身经常变动
• Marshall P. Cline, Greg A. Lomow, C++ FAQs, Addison-Wesley, 1995 记载：没有一个软件的需求改动 少于三次。唯一只改动需求两次的客户是个死人。这个可 怜的家伙还是在运送第三次需求的路上被车子撞死的。
3
Shortage of systems engineers 缺乏系统工程师
4
Shortage of software managers
缺乏了解软件特性的经理人
5
Shortage of qualified project managers
缺乏合格的项目经理
6
Shortage of software engineers
5
为什么需求很重要？
• 需求错误的代价可能会很高昂。 • Boehm和Papaccio报告，如果在需求定义过程中
找出并修复一个基于需求的问题只需花费1美元， 那么，在设计过程中做这些工作就要花费5美元， 在编码过程中就要花费10美元，在单元测试过程 中就要花费20美元，而在系统交付后要花费200 美元之多！ • 因此，花时间理解问题及其背景，然后在第一时 间内修复需求，这样做是值得的。
缺乏软件工程师
Leabharlann Baidu
7
Fixed - price contract 固定价合同
Inadequate communications for system integration 8
系统集成阶段 , 交流与沟通不充分
9
Insufficient experience as team 团队缺乏经验
10 Shortage of application domain experts
6
需求获取的任务和原则
• 导出需求变得如此困难的原因归为以下几 个方面的问题：
➢ 系统的目标或范围问题； ➢ 需求不准确性问题 ； ➢ 需求的易变问题 ；
需求获取除了需要有专业的系统分析师，还需要 通过有效的客户／开发者的合作才能成功。
客户说不清楚需求
• 有些客户心里非常清楚想要什么，但却说 不明白。
4
为什么需求很重要？
• Standish请求被调查者解释项目失败的原因： • 不完整的需求（13.1%） • 缺少用户的参与（12.4%） • 缺乏资源（10.6%） • 不切实际的期望（9.9%） • 缺乏行政支持（9.3%） • 改变需求和规格说明（8.7%） • 缺乏计划（8.1%） • 不再需要该系统（7.5%）
• 获取并理解用户的需求是软件工程师所面对的最 困难的任务之一。
为什么需求很重要？
• 1994年，Standish Group调查了350多家 公司的8000多个软件项目，了解它们的进 展情况。调查结果让人吃惊，31%的软件 项目在完成之前就取消了。另外，在大公 司中，只有9%的项目按时在预算内交付， 而在小公司中，满足这些标准的有16%。
缺乏应用领域专家
Scale: 5 = Very Serious 3 = Serious 1 = No Serious
Source: Carnegie-Mellon University, Software Engineering Institute
平均值
4.5 4.3 4.2 4.1 4.1 3.9 3.8