软件工程需求分析需求分析PPT课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
③逻辑建模——在现行系统逻辑模型的基础上，考 虑新的用户需求、限制和约束的基础上导出新系 统的逻辑模型；
④形成规约——将双方达成共识的需求文档化、模 型化，这份文档被称为“需求规约”和“需求规 格说明书”，它将是后需活动开发方努力实现的 目标
2020/7/31
7
2. 拟定“确认测试”计划
• 有了共同的需求约定以后，就可以制定“确认测试” 计划，它是用户验证软件是否满足需求的依据；
• 这个计划到综合测试后期执行。
2020/7/31
8
3. 修订开发计划
• 系统调查与可行性研究阶段的最后，草拟了初步 的开发计划，当时由于需求尚不详细，现可有了 详细的需求分析结果以后，应该使开发计划更准 确一些。
2020/7/31
9
4 . 编写“需求规划说明书”
• 需求分析阶段的成果集中体现在“需求规格说明 书”中，这是一个里程碑；
2020/7/31
21
需求获取中风验
• 需求获取隐藏着很大的风险
• 因为任何错误的需求描述，都必然造成错误的 设计、错误的编程和错误的软件结果，而实际 情形是这种潜在的风险是客观存在的
2020/7/31
22
总的原则
• 分析师关注的焦点是“做什么（What）”，而不 是“怎么做How”，系统会产生和使用什么数据？ 系统必须完成什么功能？将定义什么界面？会遇 到什么约束？等。
• 这一阶段主要精力集中在获取和分析系统的逻辑 功能上。不要把“用计算机如何实现”这样的物 理因素牵扯进来，影响逻辑功能的分析。
2020/7/31
23
5.1.4 需求分析的活动和原则
• 活动主要分为： – 需求获取； – 分析建模； – 需求评审
2020/7/31
24
分析建模
• 用户往往会从不同的角度、不同的抽象级别阐述对 原始问题的理解和需求，相对比较零乱，有必要借 助模型。
2020/7/31
16
5.1 需求分析概述
• 5.1.1 需求分析的任务、特点、主要困难 • 5.1.2 人员组成 • 5.1.3 分析师的角色 • 5.1.4 需求分析的活动和原则
2020/7/31
17
5.1.3 分析师的角色
• 是用户与开发人员的桥梁； • 与项目经理合作，是开发团队的领军人物； • 具体业务主要集中在可行性研究和需求分析阶段； • 个人素质方面：
• 有明确的格式和内容
2020/7/31
10
5. 需求评审
• 需求评审是“质量保证活动”的内容； • 体现出瀑布模型的“文档驱动”特点 • 由项目经理、用户、分析员、前一阶段（可
行性研究）的主要人员和后一阶段（概要设 计）的主要人员组成评审小组；
2020/7/31
11
阶段性成果（主要文档）包括：
2020/7/31
15
5.1.2 人员组成
• 如果是一个企业信息系统开发项目，那么项目团队 成员应包括用户和开发人员；
• 参与团队的用户包括： – 企业负责人、部门负责人、专业岗位上的员工；
• 参开团队的开发人员包括： – 系统分析师、数据管理员；
• 在需求评审时，还需要”可行性分析“和”系统设 计“阶段的主要人员参与；
2020/7/31
19
5.1.4 需求分析的活动和原则
• 活动主要分为： – 需求获取； – 分析建模； – 需求评审
2020/7/31
20
需求获取的目标
• 对用户需求进行鉴别、综合，清除用户需求的 模糊性、歧义性和不一致性；
• 把对原始问题的理解和软件开发经验结合起来， 鉴别由于用户的片面性或短期行为所导致的不 合理要求，发现用户尚未发现的但具有真正价 值的潜在需求；
13
面临的主要困难
• 需求分析活动面临的挑战： ①使用有效的软件工程方法克服复杂性 ②建立分析员与用户的有效沟通 ③使用有效的工具，克服需求表述的二义性
2020/7/31
14
5.1 需求分析概述
• 5.1.1 需求分析的任务、特点、主要困难 • 5.1.2 人员组成 • 5.1.3 分析师的角色 • 5.1.4 需求分析的活动和原则
2020/7/31
5
1. 分析建模
• 针对用户要求实现的软件功能、性能等目标， 与开发人员进一步澄清、达成共识、形成规 约;
• 准确讲，需求分析是发掘需求、分析求精、 逻辑建模、形成规约的过程。
2020/7/31
6
1. 分析建模
①发掘需求——调查需求、挖掘潜在需求、预测未 来可能的需求；
②需求求精——对模糊不清的用户需求明确、精化；
第5章 需求分析
可行性研究通过以后，下一步就要根据草拟的 开发计划，展开详细的需求分析活动。
软件需求分析，是详细分析需求，并建立需求 分析模型的阶段
2020/7/31
1
整体 概述
一 请在这里输入您的主要叙述内容
二
请在这里输入您的主要 叙述内容
三 请在这里输入您的主要叙述内容
第5章 软件需求分析
• 5.1 需求分析概述 • 5.2 结构化分析方法 • 5.3 数据流图的绘制 • 5.4 编制数据字典 • 5.5 加工逻辑的分析与表达 • 5.6 需求验证与评审
• 需求规格说明书 • 细化的项目计划 • 确认测试计划
2020/7/31
12
主要特点:
– 面向问题域（即用户业务领域） – 只关注“逻辑”，不考虑“物理”
• 只研究应该“做什么？”，暂不考虑用什么 手段、如何实现，即“怎么做”的问题；
– 用数流据图、数据字典、加工描述等工具建立 逻辑模型
2020/7/31
• 一方面，模型用于精确地记录用户从各个视角、不 同抽象级别上对原始问题及目标软件的描述；另一 方面，它将帮助分析人员去伪存真、由表及里地挖 掘用户需求。
2020/7/31
3
5.1 需求分析概述
• 5.1.1 需求分析的任务、特点、主要困难 • 5.1.2 人员组成 • 5.1.3 分析师的角色 • 5.1.4 需求分析的活动和原则
2020/7/31
4
5.1.1 需求分析的任务
1.完成“分析建模”; 2.拟定“确认测试”计划 3.修订“开发计划” 4.编写“需求规划说明书” 5.需求评审
– 具有领导才能，善于沟通； – 具有实干作风； – 知识面宽，重在广度而不是深度； – 技术全面； – 有时分析师是一个团队，由若干人承担；
2020/7/31
Байду номын сангаас
18
5.1 需求分析概述
• 5.1.1 需求分析的任务、特点、主要困难 • 5.1.2 人员组成 • 5.1.3 分析师的角色 • 5.1.4 需求分析的活动和原则
④形成规约——将双方达成共识的需求文档化、模 型化，这份文档被称为“需求规约”和“需求规 格说明书”，它将是后需活动开发方努力实现的 目标
2020/7/31
7
2. 拟定“确认测试”计划
• 有了共同的需求约定以后，就可以制定“确认测试” 计划，它是用户验证软件是否满足需求的依据；
• 这个计划到综合测试后期执行。
2020/7/31
8
3. 修订开发计划
• 系统调查与可行性研究阶段的最后，草拟了初步 的开发计划，当时由于需求尚不详细，现可有了 详细的需求分析结果以后，应该使开发计划更准 确一些。
2020/7/31
9
4 . 编写“需求规划说明书”
• 需求分析阶段的成果集中体现在“需求规格说明 书”中，这是一个里程碑；
2020/7/31
21
需求获取中风验
• 需求获取隐藏着很大的风险
• 因为任何错误的需求描述，都必然造成错误的 设计、错误的编程和错误的软件结果，而实际 情形是这种潜在的风险是客观存在的
2020/7/31
22
总的原则
• 分析师关注的焦点是“做什么（What）”，而不 是“怎么做How”，系统会产生和使用什么数据？ 系统必须完成什么功能？将定义什么界面？会遇 到什么约束？等。
• 这一阶段主要精力集中在获取和分析系统的逻辑 功能上。不要把“用计算机如何实现”这样的物 理因素牵扯进来，影响逻辑功能的分析。
2020/7/31
23
5.1.4 需求分析的活动和原则
• 活动主要分为： – 需求获取； – 分析建模； – 需求评审
2020/7/31
24
分析建模
• 用户往往会从不同的角度、不同的抽象级别阐述对 原始问题的理解和需求，相对比较零乱，有必要借 助模型。
2020/7/31
16
5.1 需求分析概述
• 5.1.1 需求分析的任务、特点、主要困难 • 5.1.2 人员组成 • 5.1.3 分析师的角色 • 5.1.4 需求分析的活动和原则
2020/7/31
17
5.1.3 分析师的角色
• 是用户与开发人员的桥梁； • 与项目经理合作，是开发团队的领军人物； • 具体业务主要集中在可行性研究和需求分析阶段； • 个人素质方面：
• 有明确的格式和内容
2020/7/31
10
5. 需求评审
• 需求评审是“质量保证活动”的内容； • 体现出瀑布模型的“文档驱动”特点 • 由项目经理、用户、分析员、前一阶段（可
行性研究）的主要人员和后一阶段（概要设 计）的主要人员组成评审小组；
2020/7/31
11
阶段性成果（主要文档）包括：
2020/7/31
15
5.1.2 人员组成
• 如果是一个企业信息系统开发项目，那么项目团队 成员应包括用户和开发人员；
• 参与团队的用户包括： – 企业负责人、部门负责人、专业岗位上的员工；
• 参开团队的开发人员包括： – 系统分析师、数据管理员；
• 在需求评审时，还需要”可行性分析“和”系统设 计“阶段的主要人员参与；
2020/7/31
19
5.1.4 需求分析的活动和原则
• 活动主要分为： – 需求获取； – 分析建模； – 需求评审
2020/7/31
20
需求获取的目标
• 对用户需求进行鉴别、综合，清除用户需求的 模糊性、歧义性和不一致性；
• 把对原始问题的理解和软件开发经验结合起来， 鉴别由于用户的片面性或短期行为所导致的不 合理要求，发现用户尚未发现的但具有真正价 值的潜在需求；
13
面临的主要困难
• 需求分析活动面临的挑战： ①使用有效的软件工程方法克服复杂性 ②建立分析员与用户的有效沟通 ③使用有效的工具，克服需求表述的二义性
2020/7/31
14
5.1 需求分析概述
• 5.1.1 需求分析的任务、特点、主要困难 • 5.1.2 人员组成 • 5.1.3 分析师的角色 • 5.1.4 需求分析的活动和原则
2020/7/31
5
1. 分析建模
• 针对用户要求实现的软件功能、性能等目标， 与开发人员进一步澄清、达成共识、形成规 约;
• 准确讲，需求分析是发掘需求、分析求精、 逻辑建模、形成规约的过程。
2020/7/31
6
1. 分析建模
①发掘需求——调查需求、挖掘潜在需求、预测未 来可能的需求；
②需求求精——对模糊不清的用户需求明确、精化；
第5章 需求分析
可行性研究通过以后，下一步就要根据草拟的 开发计划，展开详细的需求分析活动。
软件需求分析，是详细分析需求，并建立需求 分析模型的阶段
2020/7/31
1
整体 概述
一 请在这里输入您的主要叙述内容
二
请在这里输入您的主要 叙述内容
三 请在这里输入您的主要叙述内容
第5章 软件需求分析
• 5.1 需求分析概述 • 5.2 结构化分析方法 • 5.3 数据流图的绘制 • 5.4 编制数据字典 • 5.5 加工逻辑的分析与表达 • 5.6 需求验证与评审
• 需求规格说明书 • 细化的项目计划 • 确认测试计划
2020/7/31
12
主要特点:
– 面向问题域（即用户业务领域） – 只关注“逻辑”，不考虑“物理”
• 只研究应该“做什么？”，暂不考虑用什么 手段、如何实现，即“怎么做”的问题；
– 用数流据图、数据字典、加工描述等工具建立 逻辑模型
2020/7/31
• 一方面，模型用于精确地记录用户从各个视角、不 同抽象级别上对原始问题及目标软件的描述；另一 方面，它将帮助分析人员去伪存真、由表及里地挖 掘用户需求。
2020/7/31
3
5.1 需求分析概述
• 5.1.1 需求分析的任务、特点、主要困难 • 5.1.2 人员组成 • 5.1.3 分析师的角色 • 5.1.4 需求分析的活动和原则
2020/7/31
4
5.1.1 需求分析的任务
1.完成“分析建模”; 2.拟定“确认测试”计划 3.修订“开发计划” 4.编写“需求规划说明书” 5.需求评审
– 具有领导才能，善于沟通； – 具有实干作风； – 知识面宽，重在广度而不是深度； – 技术全面； – 有时分析师是一个团队，由若干人承担；
2020/7/31
Байду номын сангаас
18
5.1 需求分析概述
• 5.1.1 需求分析的任务、特点、主要困难 • 5.1.2 人员组成 • 5.1.3 分析师的角色 • 5.1.4 需求分析的活动和原则