软件需求分析的任务
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
16
1.需求变更控制
一些需求的改进是合理的且不可避免。 不被控制的变更是项目陷入混乱、不能按进度执行或软件质量 低劣的共同原因，因此，需求变更应该实现以下要求： ● 应仔细评估已建议的变更； ● 挑选合适的人选对变更做出决定； ● 变更应及时通知所有涉及的人员； ● 项目要按一定的程序来采纳需求变更。
面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开发方法 (DSSD) 面向对象的分析方法 (OOA) 等
11
C.创建数据字典 数据字典是对系统所用到的所有数据项和结构的定 义，以确保开发人员使用统一的数据定义。
12
三
定义：指应用已证实有效的技术、方法进行需求分析，确定
客户需求，帮助分析人员理解问题并定义目标系统的所有 外部特征的一门学科。
主要活动：
需求获取 需求建模（需求分析） 需求传递：编写规格（规约）说明书 需求验证 需求管理
需求工程的层次分解示意图 需求工程
需求开发
需求管理
问题获取
需求分析
编写规格说明
验证
3
3.1.3 需求错误的原因
需求描述模棱两可，有时写的过于简单； 用户的要求不断变换，需求也不断变化； 参与的用户过少，而且忽略了用户的分类； 追求个性化，添加不必要的特性。
需求越来越复杂，但很重要，现在提出了采用工 程化的思想对需求进行分析，引出需求工程的概念。
4
3.2 需求工程概述
需求分析研究的对象是软件项目的用户要求 准确地表达被接受的用户要求 确定被开发软件系统的系统元素 将功能和信息结构分配到这些系统元素中 深入描述软件的功能和性能 确定软件设计的约束和软件同其它系统元素的接口细 节 定义软件的其它有效性需求
8
2.需求分析的过程
(1) 问题识别 从系统的角度来理解软件并评审软件范围是否恰当 确定对目标系统的综合要求，即软件的需求 提出这些需求实现条件，以及需求应达到的标准
软件的需求包括：
功能需求 性能需求 环境需求 可靠性需求 安全保密要求 来自百度文库户界面需求
资源使用需求 成本消耗需求 开发进度需求 预先估计以后系统可 能达到的目标
9
问题识别的另一项工作是建立分析所需要的通信途径， 以保证能顺利地对问题进行需求分析。
10
(2) 分析与综合
A.主要任务（建立系统的逻辑模型） 从信息流和信息结构出发，逐步细化所有的软件功能， 找出系统各元素之间的联系、接口特性和设计上的约 束，分析它们是否满足功能要求，是否合理。剔除其 不合理的部分，增加其需要部分。最终综合成系统的 解决方案，给出目标系统的详细逻辑模型。 B.常用的分析方法
17
2.需求文档的版本控制 版本控制是管理需求的一个必要方面。需求文档的每一个 版本必须被统一确定，小组内每个成员必须能够得到需求的当 前版本，必须清楚地将变更写成文档，并及时通知到项目开发 所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指 定的人来更新需求。 每一个公布的需求文档的版本应该包括一个修正版本的历 史情况，即已做变更的内容、变更日期、变更人姓名以及变更 原因，可以考虑给每个需求标记上版本号，当修改满足需求后 就增加版本号。 版本控制的最有力方法是用一个商业需求管理工具的数据库 存储需求，这些工具可以跟踪和报告每个需求的变动历史， 特别是当需要恢复早期的需求时非常有意义。
3.2.1 需求开发
一. 需求获取
从用户获得需求，并整理成文档。 注：分析员与各种层析的客户进行交流，如决策人，具体使 用人，系统维护人员等等。 OOA中常采用方法：用例方法获取需求。
二. 需求分析
对上阶段获取的需求进行分析、提炼，并用相应的分析模型 描述出来，分析出高质量的需求。
7
1 主要任务：
（1）用户解决问题或达到目标所需的条件或能力； （2）系统或系统部件要满足合同、标准、规范或其它正式规定 文档所需具有的条件或能力。 （3）一种反映（1）或（2）所描述的条件或能力的文档说明。 定义从两个角度阐述需求： 用户角度 系统的外部行为 开发者角度 系统的内部特性 其关键的问题：编写需求文档。
13
被开发项目的数据流与数据结构是否足够，确定; 所有图表是否清楚，在不补充说明时能否理解; 主要功能是否已包括在规定的软件范围之内，是否都已 充分说明; 设计的约束条件或限制条件是否符合实际; 开发的技术风险是什么; 是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需求; 是否详细制定了检验标准，它们能否对系统定义是否成 功进行确认;
14
需求开发流程
15
3.2.2 需求管理
需求管理从形成需求基线开始，分析变更影响并控制变更过 程。 主要包括变更控制、版本控制和需求跟踪等活动。
变更控制就是在一定的程序下有效地实施整个变更过程；
版本管理保证了在需求文档中记录和反映所有的需求变化；
需求跟踪帮助人们全面地分析变更带来的影响，从而作出正确 的变更决策。 三者统一起来，真正做到了管理需求变化过程，以及维护需求 变化后的一致性和完整性。
需求传递（编制需求文档）
软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计划 注：格式见附录
四 需求验证（需求评审） 系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否齐全; 文档中的所有描述是否完整、清晰、准确反映用户要求; 与所有其它系统成分的重要接口是否都已经描述;
2
3.1.2 需求的层次
软件需求包括四个不同的层次： 1.业务需求：描述了组织结构或客户对系统的高层次的目标要求。 2.用户需求：描述了用户使用产品必须要完成的任务，使用实例模型描述。 3.功能需求：定义了开发人员实现的软件的功能。 4.业务需求：描述系统的约束和限制条件。
注：以上需求应详细的写到软件需求规格说明书里。
第三章 需求工程
需求阶段是软件开发的关键阶段。 该阶段的主要任务： 必须回答一个问题：“系统 应该做什么（what）”。 所涉及的人员有：领域专家、领域用户、软件投资 人、系统分析员和需求分析员。
该阶段的工作量约占总工作量的10%以上。
1
3.1 软件需求
3.1.1 软件需求的定义 IEEE软件工程标准词汇表（1997年）将需求定义为：
1.需求变更控制
一些需求的改进是合理的且不可避免。 不被控制的变更是项目陷入混乱、不能按进度执行或软件质量 低劣的共同原因，因此，需求变更应该实现以下要求： ● 应仔细评估已建议的变更； ● 挑选合适的人选对变更做出决定； ● 变更应及时通知所有涉及的人员； ● 项目要按一定的程序来采纳需求变更。
面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开发方法 (DSSD) 面向对象的分析方法 (OOA) 等
11
C.创建数据字典 数据字典是对系统所用到的所有数据项和结构的定 义，以确保开发人员使用统一的数据定义。
12
三
定义：指应用已证实有效的技术、方法进行需求分析，确定
客户需求，帮助分析人员理解问题并定义目标系统的所有 外部特征的一门学科。
主要活动：
需求获取 需求建模（需求分析） 需求传递：编写规格（规约）说明书 需求验证 需求管理
需求工程的层次分解示意图 需求工程
需求开发
需求管理
问题获取
需求分析
编写规格说明
验证
3
3.1.3 需求错误的原因
需求描述模棱两可，有时写的过于简单； 用户的要求不断变换，需求也不断变化； 参与的用户过少，而且忽略了用户的分类； 追求个性化，添加不必要的特性。
需求越来越复杂，但很重要，现在提出了采用工 程化的思想对需求进行分析，引出需求工程的概念。
4
3.2 需求工程概述
需求分析研究的对象是软件项目的用户要求 准确地表达被接受的用户要求 确定被开发软件系统的系统元素 将功能和信息结构分配到这些系统元素中 深入描述软件的功能和性能 确定软件设计的约束和软件同其它系统元素的接口细 节 定义软件的其它有效性需求
8
2.需求分析的过程
(1) 问题识别 从系统的角度来理解软件并评审软件范围是否恰当 确定对目标系统的综合要求，即软件的需求 提出这些需求实现条件，以及需求应达到的标准
软件的需求包括：
功能需求 性能需求 环境需求 可靠性需求 安全保密要求 来自百度文库户界面需求
资源使用需求 成本消耗需求 开发进度需求 预先估计以后系统可 能达到的目标
9
问题识别的另一项工作是建立分析所需要的通信途径， 以保证能顺利地对问题进行需求分析。
10
(2) 分析与综合
A.主要任务（建立系统的逻辑模型） 从信息流和信息结构出发，逐步细化所有的软件功能， 找出系统各元素之间的联系、接口特性和设计上的约 束，分析它们是否满足功能要求，是否合理。剔除其 不合理的部分，增加其需要部分。最终综合成系统的 解决方案，给出目标系统的详细逻辑模型。 B.常用的分析方法
17
2.需求文档的版本控制 版本控制是管理需求的一个必要方面。需求文档的每一个 版本必须被统一确定，小组内每个成员必须能够得到需求的当 前版本，必须清楚地将变更写成文档，并及时通知到项目开发 所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指 定的人来更新需求。 每一个公布的需求文档的版本应该包括一个修正版本的历 史情况，即已做变更的内容、变更日期、变更人姓名以及变更 原因，可以考虑给每个需求标记上版本号，当修改满足需求后 就增加版本号。 版本控制的最有力方法是用一个商业需求管理工具的数据库 存储需求，这些工具可以跟踪和报告每个需求的变动历史， 特别是当需要恢复早期的需求时非常有意义。
3.2.1 需求开发
一. 需求获取
从用户获得需求，并整理成文档。 注：分析员与各种层析的客户进行交流，如决策人，具体使 用人，系统维护人员等等。 OOA中常采用方法：用例方法获取需求。
二. 需求分析
对上阶段获取的需求进行分析、提炼，并用相应的分析模型 描述出来，分析出高质量的需求。
7
1 主要任务：
（1）用户解决问题或达到目标所需的条件或能力； （2）系统或系统部件要满足合同、标准、规范或其它正式规定 文档所需具有的条件或能力。 （3）一种反映（1）或（2）所描述的条件或能力的文档说明。 定义从两个角度阐述需求： 用户角度 系统的外部行为 开发者角度 系统的内部特性 其关键的问题：编写需求文档。
13
被开发项目的数据流与数据结构是否足够，确定; 所有图表是否清楚，在不补充说明时能否理解; 主要功能是否已包括在规定的软件范围之内，是否都已 充分说明; 设计的约束条件或限制条件是否符合实际; 开发的技术风险是什么; 是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需求; 是否详细制定了检验标准，它们能否对系统定义是否成 功进行确认;
14
需求开发流程
15
3.2.2 需求管理
需求管理从形成需求基线开始，分析变更影响并控制变更过 程。 主要包括变更控制、版本控制和需求跟踪等活动。
变更控制就是在一定的程序下有效地实施整个变更过程；
版本管理保证了在需求文档中记录和反映所有的需求变化；
需求跟踪帮助人们全面地分析变更带来的影响，从而作出正确 的变更决策。 三者统一起来，真正做到了管理需求变化过程，以及维护需求 变化后的一致性和完整性。
需求传递（编制需求文档）
软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计划 注：格式见附录
四 需求验证（需求评审） 系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否齐全; 文档中的所有描述是否完整、清晰、准确反映用户要求; 与所有其它系统成分的重要接口是否都已经描述;
2
3.1.2 需求的层次
软件需求包括四个不同的层次： 1.业务需求：描述了组织结构或客户对系统的高层次的目标要求。 2.用户需求：描述了用户使用产品必须要完成的任务，使用实例模型描述。 3.功能需求：定义了开发人员实现的软件的功能。 4.业务需求：描述系统的约束和限制条件。
注：以上需求应详细的写到软件需求规格说明书里。
第三章 需求工程
需求阶段是软件开发的关键阶段。 该阶段的主要任务： 必须回答一个问题：“系统 应该做什么（what）”。 所涉及的人员有：领域专家、领域用户、软件投资 人、系统分析员和需求分析员。
该阶段的工作量约占总工作量的10%以上。
1
3.1 软件需求
3.1.1 软件需求的定义 IEEE软件工程标准词汇表（1997年）将需求定义为：