需求分析具体要求
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
的目标要求。 • 用户需求：从用户使用的角度给出需求的描述。
如一个小型超市需要一个商品的查询系统。 业务需求：进货人员需要查询商品库存以便保证及 时进货；收款员需要查询商品的销售价格以便结账； 经理需要查询商品的销售及盈利情况。 用户需求:这三类用户怎样去查询系统，查询哪些 信息，还需要哪些操作。
• 系统需求：从系统的角度描述要提供的服务以及所受到的约 束。
需求分析是软件定义时期的最后一个阶段， 它的基本任务不是确定系统怎样完成它的工作， 而是确定系统必须完成哪些工作，也就是对目标 系统提出完整、准确、清晰、具体的要求。
并在在需求分析阶段结束之前，由系统分析 员写出软件需求规格说明书，以书面形式准确地 描述软件需求。即：
---- 准确地回答“系统必须做什么?”。
➢ 需求获取和分析有一定的难度，因为：
1）项目相关人员通常并不真正知道希望计算机 做什么，让他们清晰的表达出需要系统做什么是件 困难的事，他们或许提出不切实际的要求。
2） 项目相关人员用自己的语言表达需求，这些 语言包含很多工作中的专业术语和专业知识。系统分 析员没有这些知识和经验，而他们又必须了解这些需 求。
面向数据流自顶向下求精
3.2.3 简易的应用规格说明技术
提倡用户与开发者密切合作，共同标识问题，提出解决方 案要素，商讨不同方案并指定基本需求
- 进行初步的访谈 - 开发者和用户双方组织的代表出席会议 - 每个小组为每张列表中的项目制定小型规格说明 - 根据会议成果起草完整的软件需求规格说明书
3.3 分析建模与规格说明
第3章 需求分析
3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 （？） 3.5 数据规范化（？） 3.6 状态转换图+有穷状态机 3.7 其他图形工具 3.8 验证软件需求 3.9 小结
需求分析的意义
软件需求的深入理解是软件开发工作获得成 功的前提条件，不论我们把设计和编码做得如何 出色，不能真正满足用户需求的程序只会令用户 失望，给开发带来烦恼。
软件需求规格说明书，是需求分析阶段得出的最主要 的文档。
软件需求说明书的编写提示（GB856T—88）
1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料
2 任务概述 2.1 目标 2.2 用户的特点 2.3 假定和约束
软件需求说明书的编写提示（GB856T—88）
3 需求规定
在分析软件需求和书写软件需求规格说明书的过程中， 分析员和用户都起着关键的、必不可少的作用。
软件需求的组成
业务需求
项目范 围文档
用户需求
文档
质量属性 非功能需求
其他非功 能需求
系统需求
设计约束
功能需求
需求规约 (specification)
需求组成的全景图
其中： • 业务需求：反映组织机构和客户对系统、产品高层次
• 需求获取的方法：个别访谈、召集会议、文档研究、 问卷调查、观察用户工作流程、建立原型。
• 获取的需求的表达方式： （1）需求列表 需求与系统的特殊视角或环境的关系
（2）业务流程图（状态/活动图） （3）数据流图 （4）实体-联系图
3.2 与用户沟通获取需求的方法
➢ 3.2.1 访谈 ➢ 3.2.2 面向数据流自顶向下求精 ➢ 3.2.3 简易的应用规格说明技术 ➢ 3.2.4 快速建立软件原型
3）不同的项目相关人员有不同的需求，可能以不同 的方式表达，分析人员必须发现所有潜在的需求资源， 而且能发现这些需求的相容或冲突之处。
4）经济和业务环境决定了分析是动态的，需求在分 析过程中会发生变更。个别需求的重要程度会改变， 新的需求会从新的项目相关人员那里得到。
需求获取技术
• 建立由客户（用户）、系统分析员、领域专家参加的 联合小组。
1). 分析建模
模型
----就是为了理解事物而对事物做出的一种抽象，是对事 物的一种无歧义的书面描述。通常，由一组图形符号和组 织这些符号的规则组成。
建模方法
在过去的数年中，人们提出了许多种分析建模的方法，其中两种在 分析建模领域占有主导地位：
第一种是结构化分析 (Structured Analysis，SA)，70年代末由 DeMarco等人提出，这是传统的建模方法。该方法不是被所有的使用者 一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发展 了超过30年的一个混合物。
• 功能性需求：描述系统应该做什么，即为用户和其它系统完 成的功能、提供的服务。
• 非功能性需求：产品必须具备的属性或品质。 • 设计约束：设计与实现必须遵循的标准、约束条件。如运行
平台、协议、选择的技术、编程语言和工具等。
软件需求的描述
• 结构化语言、PDL • 图形化表示 • 数学描述（形式化语言描述）
具体的建模方法/表达方式有：
面向流的建模：数据流图（DFD/CFD） 数据建模：实体关系图（ERD） 基于行为的建模： Petri网、状态图
3.3.2 软件需求规格说明(SRS)
Software Requirement Specification
通常用自然语言+模型，完整、准确、具体地描述系 统的数据要求、功能需求、性能需求、可靠性和可用性 要求、出错处理需求、接口需求、约束、逆向需求以及 将来可能提出的要求。
3.1 需求分析的具体任务
1 确定对系统的综合要求
---功能需求、性能需求、可靠性和可用性 需求、出错处理需求、接口需求、约束、 逆向需求、将来可能提出的要求。
2 分析系统的数据要求
3 导出系统的逻辑模型
4 修正系统开发计划
软件需求获取
需求分析是一个包括创建和维持系统需求文档所必需的一 切活动的过程。它包含了如下活动：
需求获取和分析、需求描述和文档编写、需求有效性验证、 需求管理（管理需求工程的变更）。
需求获取 和分析
系统模型
需求管理
需求描述
用户ห้องสมุดไป่ตู้求和系 统需求
需求有效 性验证
软件需求过程
需求规约
➢ 需求获取是开发人员与客户或用户一起对应用领域 进行调查研究，收集系统需求的过程。
➢ 需求分析是将获取到的需求准确的理解、求精，并 将其转化为完整的需求定义（包括建模），进而生 成需求规约的过程。
如一个小型超市需要一个商品的查询系统。 业务需求：进货人员需要查询商品库存以便保证及 时进货；收款员需要查询商品的销售价格以便结账； 经理需要查询商品的销售及盈利情况。 用户需求:这三类用户怎样去查询系统，查询哪些 信息，还需要哪些操作。
• 系统需求：从系统的角度描述要提供的服务以及所受到的约 束。
需求分析是软件定义时期的最后一个阶段， 它的基本任务不是确定系统怎样完成它的工作， 而是确定系统必须完成哪些工作，也就是对目标 系统提出完整、准确、清晰、具体的要求。
并在在需求分析阶段结束之前，由系统分析 员写出软件需求规格说明书，以书面形式准确地 描述软件需求。即：
---- 准确地回答“系统必须做什么?”。
➢ 需求获取和分析有一定的难度，因为：
1）项目相关人员通常并不真正知道希望计算机 做什么，让他们清晰的表达出需要系统做什么是件 困难的事，他们或许提出不切实际的要求。
2） 项目相关人员用自己的语言表达需求，这些 语言包含很多工作中的专业术语和专业知识。系统分 析员没有这些知识和经验，而他们又必须了解这些需 求。
面向数据流自顶向下求精
3.2.3 简易的应用规格说明技术
提倡用户与开发者密切合作，共同标识问题，提出解决方 案要素，商讨不同方案并指定基本需求
- 进行初步的访谈 - 开发者和用户双方组织的代表出席会议 - 每个小组为每张列表中的项目制定小型规格说明 - 根据会议成果起草完整的软件需求规格说明书
3.3 分析建模与规格说明
第3章 需求分析
3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 （？） 3.5 数据规范化（？） 3.6 状态转换图+有穷状态机 3.7 其他图形工具 3.8 验证软件需求 3.9 小结
需求分析的意义
软件需求的深入理解是软件开发工作获得成 功的前提条件，不论我们把设计和编码做得如何 出色，不能真正满足用户需求的程序只会令用户 失望，给开发带来烦恼。
软件需求规格说明书，是需求分析阶段得出的最主要 的文档。
软件需求说明书的编写提示（GB856T—88）
1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料
2 任务概述 2.1 目标 2.2 用户的特点 2.3 假定和约束
软件需求说明书的编写提示（GB856T—88）
3 需求规定
在分析软件需求和书写软件需求规格说明书的过程中， 分析员和用户都起着关键的、必不可少的作用。
软件需求的组成
业务需求
项目范 围文档
用户需求
文档
质量属性 非功能需求
其他非功 能需求
系统需求
设计约束
功能需求
需求规约 (specification)
需求组成的全景图
其中： • 业务需求：反映组织机构和客户对系统、产品高层次
• 需求获取的方法：个别访谈、召集会议、文档研究、 问卷调查、观察用户工作流程、建立原型。
• 获取的需求的表达方式： （1）需求列表 需求与系统的特殊视角或环境的关系
（2）业务流程图（状态/活动图） （3）数据流图 （4）实体-联系图
3.2 与用户沟通获取需求的方法
➢ 3.2.1 访谈 ➢ 3.2.2 面向数据流自顶向下求精 ➢ 3.2.3 简易的应用规格说明技术 ➢ 3.2.4 快速建立软件原型
3）不同的项目相关人员有不同的需求，可能以不同 的方式表达，分析人员必须发现所有潜在的需求资源， 而且能发现这些需求的相容或冲突之处。
4）经济和业务环境决定了分析是动态的，需求在分 析过程中会发生变更。个别需求的重要程度会改变， 新的需求会从新的项目相关人员那里得到。
需求获取技术
• 建立由客户（用户）、系统分析员、领域专家参加的 联合小组。
1). 分析建模
模型
----就是为了理解事物而对事物做出的一种抽象，是对事 物的一种无歧义的书面描述。通常，由一组图形符号和组 织这些符号的规则组成。
建模方法
在过去的数年中，人们提出了许多种分析建模的方法，其中两种在 分析建模领域占有主导地位：
第一种是结构化分析 (Structured Analysis，SA)，70年代末由 DeMarco等人提出，这是传统的建模方法。该方法不是被所有的使用者 一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发展 了超过30年的一个混合物。
• 功能性需求：描述系统应该做什么，即为用户和其它系统完 成的功能、提供的服务。
• 非功能性需求：产品必须具备的属性或品质。 • 设计约束：设计与实现必须遵循的标准、约束条件。如运行
平台、协议、选择的技术、编程语言和工具等。
软件需求的描述
• 结构化语言、PDL • 图形化表示 • 数学描述（形式化语言描述）
具体的建模方法/表达方式有：
面向流的建模：数据流图（DFD/CFD） 数据建模：实体关系图（ERD） 基于行为的建模： Petri网、状态图
3.3.2 软件需求规格说明(SRS)
Software Requirement Specification
通常用自然语言+模型，完整、准确、具体地描述系 统的数据要求、功能需求、性能需求、可靠性和可用性 要求、出错处理需求、接口需求、约束、逆向需求以及 将来可能提出的要求。
3.1 需求分析的具体任务
1 确定对系统的综合要求
---功能需求、性能需求、可靠性和可用性 需求、出错处理需求、接口需求、约束、 逆向需求、将来可能提出的要求。
2 分析系统的数据要求
3 导出系统的逻辑模型
4 修正系统开发计划
软件需求获取
需求分析是一个包括创建和维持系统需求文档所必需的一 切活动的过程。它包含了如下活动：
需求获取和分析、需求描述和文档编写、需求有效性验证、 需求管理（管理需求工程的变更）。
需求获取 和分析
系统模型
需求管理
需求描述
用户ห้องสมุดไป่ตู้求和系 统需求
需求有效 性验证
软件需求过程
需求规约
➢ 需求获取是开发人员与客户或用户一起对应用领域 进行调查研究，收集系统需求的过程。
➢ 需求分析是将获取到的需求准确的理解、求精，并 将其转化为完整的需求定义（包括建模），进而生 成需求规约的过程。