高级软件工程需求分析
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求规约为软件设计师和客户提供了软件建造 完后，进行质量评估的依据。
1.软件需求的概念和分类
比较权威的需求的定义来自于IEEE软件工程标准词汇 表中的定义：
l 用户解决问题或达到目标所需要的条件。 l 系统或系统部件要满足合同、标准、规范或其他
正式规定的文档所要具有的条件。
l 反映上面两条的文档说明。
将来可能提出的要求：应该明确地列出那些虽 然不属于当前系统开发范畴，但是据分析将来 很可能会提出来的要求。
另一种分类
功能性需求 产品的范围 功能与数据需求
非功能性需求 观感需求 易用性 性能
限制条件
操作需求 可维护性和可移植性需求 安全性需求 文化与政策 法律需求
接口需求：描述应用系统与其环境通信的格式， 常见的接口需求有用户接口需求、硬件接口需 求、软件接口需求和通信接口需求；
约束：描述了应用系统应遵守的限制条件，常 见的约束有：精度约束、工具和语言约束、设 计约束、应该使用的标准、应该使用的硬件平 台等；
逆向需求：说明软件系统不应该做什么。理论 上有无限多个逆向需求，我们应该仅选取能澄 清真实需求且可消除发生误解的那些逆向需求；
需求一方面反映了系统的外部行为，另一方面反映了 系统的内部特性，反映的方式是需求文档。
比较通俗的需求定义如下：需求是指明系统必须实现 什么的规格说明，它描述了系统的行为、特性或属性， 是在开发过程中对系统的约束。
需求分析的难点
问题的复杂性 交流障碍 不完备性和不一致性 易变性
外部接口——与人、硬件、其他软件和其他硬 件的相互关系。
软件需求规格说明的大纲
1 前言 1.1 目的 1.2 范围 1.3 定义、缩写词、略语 1.4 参考资料 2 项目概述 2.1 产品描述 2.2 产品功能 2.3 用户特点 2.4 一般约束
2.5 假设和依据
3 具体需求 3.1 功能需求 3.1.1 功能需求1 3.1.1.1 引言 3.1.1.2 输入 3.1.1.3 加工 3.1.1.4 输出 3.1.2 功能需求2 ……
3.2软件需求分析基础：以结 构化分析方法为例
3.1.2.需求分析的任务
需求分析的任务是借助于当前系统的物理模型 导出目标系统的逻辑模型，解决目标系统“做 什么”的问题。
所要做的工作是深入描述软件的功能和性能， 确定软件设计的限制和软件同其他系统元素的 接口细节，定义软件的其他有效性需求。
必须全面理解用户的各项要求，但只能接受合 理的要求。
客户和系统分析员之间最常用的交流方式，是 通过预备会议或访谈进行的。
获取用户需求的主要方法是调查研究。
做好准备 制定调研计划 准备调研资料 访谈用户 写调研报告 评审
需求分析阶段的文档
软件需求说明书 初步的用户手册 修改、完善与确定软件开发实施计划
3.1.4 需求规格说明
软件需求规格说明是分析任务的最终产物，美 国国家标准局、IEEE（标准号830－1984） 以及美国防部门均已提出了软件需求规约（以 及其他软件工程文档）的候选格式。
软件需求规格说明必须正确地定义所有的软件 需求；除了设计上的特殊限制之外，软件需求 规格说明中一般不描述任何设计、验证或项目 管理的细节。
需求的类别
功能需求：指定系统必须提供的服务，通过需 求分析应该划分出系统必须完成的所有功能；
性能需求：指定系统必须满足的定时约束或容 量约束，通常包括速度（响应时间）、信息量 速率、主存容量、磁盘容量、安全Hale Waihona Puke Baidu等方面的 需求；
可靠性和可用性需求：定量地指定系统的可靠 性与可用性；
出错处理需求：说明系统对环境错误应该怎样 响应；
高级软件工程（3）
3.1 需求分析的任务
需求分析的基本任务是准确地回答“系统必须做什 么？”这一核心问题。
3.1.1 需求分析的概念
需求分析是一种软件工程活动，使得系统分析 员能够刻划出软件的功能和性能、指明软件和 其他系统元素的接口、并建立软件必须满足的 约束。
需求分析是软件设计师进行软件分解的基础， 需求分析建造了软件处理的数据模型、功能模 型和行为模型。
需求必须描述的基本问题
功能——所设计的软件要做什么； 性能——软件功能在执行过程中的速度、可使
用性、响应时间、各种软件功能的恢复时间、 吞吐能力、精度、频率等等；
强加给实现的设计限制——在效果、实现的语 言、数据库完整性、资源限制、操作环境等等 方面所要求的标准；
属性——可移植性、正确性、可维护性及安全 性等方面的考虑因素；
要将软件的需求准确地表达出来，形成软件需 求说明书。
怎么做
模型化
当前系统
物理模型
做什么
抽象化 逻辑模型
具体化
目标系统
物理模型
实例化 逻辑模型
理
导 出
解 需 求
表 达 需 求
需求分析的任务
获得当前系统的物理模型：首先，分析、理解 当前系统是如何运行的，并用一个具体的模型来 反映自己对当前系统的理解。 抽象出当前系统的逻辑模型：在理解当前系统 “怎样做”的基础上，取出非本质因素，抽取出 “做什么”的本质。
建立目标系统的逻辑模型：分析目标系统与当 前系统逻辑上的差别，明确目标系统要“做什 么”，从而从当前系统的逻辑模型中，导出目标 系统的逻辑模型。
对目标系统逻辑模型进行补充：具体内容如 用户界面、启动和结束、出错处理、系统输入输 出、系统性能、其他限制等等。
3.1.2 需求获取
软件需求分析中需要很好的的相互沟通，沟通 总是要在两方或多方间进行。
3.1.n 功能需求n
3.2 外部接口需求 3.2.1 用户接口 3.2.2 硬件接口 3.2.3 软件接口 3.2.4 通信接口 3.3 性能需求 3.4 设计约束 3.4.1 其他标准的约束 3.4.2 硬件的限制 …………
3.5 属性 3.5.1 安全性 3.5.2 可维护性 ………… 3.6 其他需求 3.6.1 数据库 3.6.2 操作 3.6.3 场合适应性 ………… 附录 索引
1.软件需求的概念和分类
比较权威的需求的定义来自于IEEE软件工程标准词汇 表中的定义：
l 用户解决问题或达到目标所需要的条件。 l 系统或系统部件要满足合同、标准、规范或其他
正式规定的文档所要具有的条件。
l 反映上面两条的文档说明。
将来可能提出的要求：应该明确地列出那些虽 然不属于当前系统开发范畴，但是据分析将来 很可能会提出来的要求。
另一种分类
功能性需求 产品的范围 功能与数据需求
非功能性需求 观感需求 易用性 性能
限制条件
操作需求 可维护性和可移植性需求 安全性需求 文化与政策 法律需求
接口需求：描述应用系统与其环境通信的格式， 常见的接口需求有用户接口需求、硬件接口需 求、软件接口需求和通信接口需求；
约束：描述了应用系统应遵守的限制条件，常 见的约束有：精度约束、工具和语言约束、设 计约束、应该使用的标准、应该使用的硬件平 台等；
逆向需求：说明软件系统不应该做什么。理论 上有无限多个逆向需求，我们应该仅选取能澄 清真实需求且可消除发生误解的那些逆向需求；
需求一方面反映了系统的外部行为，另一方面反映了 系统的内部特性，反映的方式是需求文档。
比较通俗的需求定义如下：需求是指明系统必须实现 什么的规格说明，它描述了系统的行为、特性或属性， 是在开发过程中对系统的约束。
需求分析的难点
问题的复杂性 交流障碍 不完备性和不一致性 易变性
外部接口——与人、硬件、其他软件和其他硬 件的相互关系。
软件需求规格说明的大纲
1 前言 1.1 目的 1.2 范围 1.3 定义、缩写词、略语 1.4 参考资料 2 项目概述 2.1 产品描述 2.2 产品功能 2.3 用户特点 2.4 一般约束
2.5 假设和依据
3 具体需求 3.1 功能需求 3.1.1 功能需求1 3.1.1.1 引言 3.1.1.2 输入 3.1.1.3 加工 3.1.1.4 输出 3.1.2 功能需求2 ……
3.2软件需求分析基础：以结 构化分析方法为例
3.1.2.需求分析的任务
需求分析的任务是借助于当前系统的物理模型 导出目标系统的逻辑模型，解决目标系统“做 什么”的问题。
所要做的工作是深入描述软件的功能和性能， 确定软件设计的限制和软件同其他系统元素的 接口细节，定义软件的其他有效性需求。
必须全面理解用户的各项要求，但只能接受合 理的要求。
客户和系统分析员之间最常用的交流方式，是 通过预备会议或访谈进行的。
获取用户需求的主要方法是调查研究。
做好准备 制定调研计划 准备调研资料 访谈用户 写调研报告 评审
需求分析阶段的文档
软件需求说明书 初步的用户手册 修改、完善与确定软件开发实施计划
3.1.4 需求规格说明
软件需求规格说明是分析任务的最终产物，美 国国家标准局、IEEE（标准号830－1984） 以及美国防部门均已提出了软件需求规约（以 及其他软件工程文档）的候选格式。
软件需求规格说明必须正确地定义所有的软件 需求；除了设计上的特殊限制之外，软件需求 规格说明中一般不描述任何设计、验证或项目 管理的细节。
需求的类别
功能需求：指定系统必须提供的服务，通过需 求分析应该划分出系统必须完成的所有功能；
性能需求：指定系统必须满足的定时约束或容 量约束，通常包括速度（响应时间）、信息量 速率、主存容量、磁盘容量、安全Hale Waihona Puke Baidu等方面的 需求；
可靠性和可用性需求：定量地指定系统的可靠 性与可用性；
出错处理需求：说明系统对环境错误应该怎样 响应；
高级软件工程（3）
3.1 需求分析的任务
需求分析的基本任务是准确地回答“系统必须做什 么？”这一核心问题。
3.1.1 需求分析的概念
需求分析是一种软件工程活动，使得系统分析 员能够刻划出软件的功能和性能、指明软件和 其他系统元素的接口、并建立软件必须满足的 约束。
需求分析是软件设计师进行软件分解的基础， 需求分析建造了软件处理的数据模型、功能模 型和行为模型。
需求必须描述的基本问题
功能——所设计的软件要做什么； 性能——软件功能在执行过程中的速度、可使
用性、响应时间、各种软件功能的恢复时间、 吞吐能力、精度、频率等等；
强加给实现的设计限制——在效果、实现的语 言、数据库完整性、资源限制、操作环境等等 方面所要求的标准；
属性——可移植性、正确性、可维护性及安全 性等方面的考虑因素；
要将软件的需求准确地表达出来，形成软件需 求说明书。
怎么做
模型化
当前系统
物理模型
做什么
抽象化 逻辑模型
具体化
目标系统
物理模型
实例化 逻辑模型
理
导 出
解 需 求
表 达 需 求
需求分析的任务
获得当前系统的物理模型：首先，分析、理解 当前系统是如何运行的，并用一个具体的模型来 反映自己对当前系统的理解。 抽象出当前系统的逻辑模型：在理解当前系统 “怎样做”的基础上，取出非本质因素，抽取出 “做什么”的本质。
建立目标系统的逻辑模型：分析目标系统与当 前系统逻辑上的差别，明确目标系统要“做什 么”，从而从当前系统的逻辑模型中，导出目标 系统的逻辑模型。
对目标系统逻辑模型进行补充：具体内容如 用户界面、启动和结束、出错处理、系统输入输 出、系统性能、其他限制等等。
3.1.2 需求获取
软件需求分析中需要很好的的相互沟通，沟通 总是要在两方或多方间进行。
3.1.n 功能需求n
3.2 外部接口需求 3.2.1 用户接口 3.2.2 硬件接口 3.2.3 软件接口 3.2.4 通信接口 3.3 性能需求 3.4 设计约束 3.4.1 其他标准的约束 3.4.2 硬件的限制 …………
3.5 属性 3.5.1 安全性 3.5.2 可维护性 ………… 3.6 其他需求 3.6.1 数据库 3.6.2 操作 3.6.3 场合适应性 ………… 附录 索引