第3章 软件需求分析(讲)
合集下载
自考软件工程第3章知识点总结
2
第3章 软件需求分析
需求分析在软件开发中所处的地位愈加突出，从而也愈加 困难，它的难点主要体现在以下几个方面：
(1) 问题的复杂性。 (2) 交流障碍。 (3) 不完备性和不一致性。 (4) 需求易变性。
软件需求分析与说明的方法的基本原则：
(1) 必须能够表达和理解问题的数据域和功能域。 (2) 可以把一个复杂问题按功能进行分解并可逐层细化。 (3) 建模。
结构化分析（Structured Analysis，简称SA），是面向数 据流进行需求分析的方法。根据软件内部数据传递、变换的关 系，自顶向下逐层分解，描绘出满足功能要求的软件模型。
3.2.1自项向下逐层分解的分析策略
面对一个复杂的问题，采取分解的策略，把一个复杂的问
题划分成若干小问题，然后再分别解决。分解可分层进行，在
(3) 环境需求。 (4) 用户界面需求。
4
第3章 软件需求分析
2. 分析与综合， 导出软件的逻辑模型 分析人员对获取的需求，进行一致性的分析检查，在 分析、 综合中逐步细分软件功能，划分成各个子功能。 3. 编写文档 编写文档的步骤如下： (1) 编写“需求说明书。 (2) 编写初步用户使用手册。 (3) 编写确认测试计划。 (4) 修改完善项目开发计划。
3. 数据项条目 数据项条目是不可再分解的最小数据单位， 其定义格 式及举例如下： 数据项名称： 货物编号 别名： G-No， G-num, Goods-No 简述： 本公司的所有货物的编号 类型： 字符串 长度： 10
取值范围及含义： 第1位： 进口/国产
第2～4位： 类别 第5～7位： 规格
第8～10位： 品名编号
1. 数据流条目
数据流条目给出了DFD中数据流的定义，通常列出该数 据流的各组成数据项。
软件工程第3章 软件需求分析(终)
第3章软件需求分析案例3: 图书馆图书信息管理系统“图书馆管理系统”是借助计算机来完成图书馆日常管理工作，能提供借书帐号注册、登录功能，基于图书标题、图书编号、作者、出版社的查询，也可以同时多个选项进行同时查询提供图书状态的查询，如可借和不可借，完成借书登记、还书的登记，能帮助管理人员完成图书信息的管理，如图书信息的修改、新图书的增加、旧图书的删除，图书分类工作，从而使图书馆的日常工作信息化、快捷化，减轻图书馆管理工作的困难。
因此，“图书馆管理系统”对于图书馆的日常管理工作和信息化到至关重要的作用。
【知识导入】通过对本章节内容的学习，掌握软件需求分析的基本内容，需求分析的特征及评审。
能够完成项目的需求分析，确立正确的项目开发思路。
软件需求是一个项目的开端，是整个软件项目开发的基础。
即表示该软件经过可行性分析后确立有此需求，而开发该项目。
因此，需求分析在整个项目建设过程中至关重要，是项目开发的基石，基石的牢固程度决定了后期项目的进展以及项目开发完工后的产品质量的优劣，可以说需求分析的好坏直接影响到软件项目开发的成败。
软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。
IEEE （美国电气和电子工程师协会）是这样对需求分析做定义的：①用户解决问题或达到系统目标所需要的条件②为满足一个协议、标准、规格或其他正式制定的文档，系统或系统构建所需满足和具有的条件或能力③将需求要求条件进行文档化描述。
这个概念全方位阐述了需求的概念，较完整的表达了软件需求的内涵和外延，便于用户的全面理解。
而需求分析最终就是通过对应用问题及其环境的分析与理解采用一系列的分析方法和技术将用户的需求逐步精确化、完全化、一致化，最终形成需求规格说明文档的过程。
系统分析阶段产生的系统规格说明书和项目规划是软件需求分析的基础，分析人员需要从软件的角度对其进行检查和调整，并在此基础上展开需求分析。
需求分析阶段的成果主要是需求规格说明书，该成果又是软件设计、编码、测试直至维护的主要基础。
第3章软件需求分析与建模
应如何实施。
2020/3/7第3章软件需求分析与建模
软件工程教研室
15
①数据模型 描述对象系统的本质属性及其关系。常用的建模工具有 实体-联系图等。 ②功能模型 描述对象系统所能实现的所有功能。而不考虑每个功能 实现的次序。常用的建模工具有数据流图、IDEF0等。 ③行为模型 描述对象系统为实现某项功能而发生的动态行为。常用 的建模工具有控制流图、状态转换图等。
2020/3/7第3章软件需求分析与建模
软件工程教研室
24
X
1
3
2
1.1 1.3 1.2
2.2
2.1
2.3
3.2
3.1
3.3
图3-3 自顶向下逐层分解图
2020/3/7第3章软件需求分析与建模
软件工程教研室
25
结构化分析的过程如下 1．建立当前系统（现在工作方式）的概念模型。系统的 概念模型就是现实环境的忠实写照，可用系统流程图来表 示。这样的表达与当前系统完全对应，用户容易理解。 2．抽象出当前系统的逻辑模型。分析系统的概念模型， 抽象出其本质的因素，排除次要因素，获得用数据流图 DFD 图等描述的当前系统的逻辑模型。 3．建立目标系统的逻辑模型。分析目标系统与当前系统 逻辑上的差别，从而进一步明确目标系统“做什么”，建 立目标系统的“逻辑模型”(修改后的数据流图DFD 图等)。 4．建立人机交互接口和其他必要的模型，确定各种方案 的成本和风险等级，据此对各种方案进行分析，选择其中 一种方案，建立完整的需求规约。 分析模型的结构如图3-4所示。
Y
用户和设计者是否满意
N
运行原型
是否放弃
Y
N
把原型作为 把原型作为应 应用系统 用系统开发的
2020/3/7第3章软件需求分析与建模
软件工程教研室
15
①数据模型 描述对象系统的本质属性及其关系。常用的建模工具有 实体-联系图等。 ②功能模型 描述对象系统所能实现的所有功能。而不考虑每个功能 实现的次序。常用的建模工具有数据流图、IDEF0等。 ③行为模型 描述对象系统为实现某项功能而发生的动态行为。常用 的建模工具有控制流图、状态转换图等。
2020/3/7第3章软件需求分析与建模
软件工程教研室
24
X
1
3
2
1.1 1.3 1.2
2.2
2.1
2.3
3.2
3.1
3.3
图3-3 自顶向下逐层分解图
2020/3/7第3章软件需求分析与建模
软件工程教研室
25
结构化分析的过程如下 1．建立当前系统（现在工作方式）的概念模型。系统的 概念模型就是现实环境的忠实写照，可用系统流程图来表 示。这样的表达与当前系统完全对应，用户容易理解。 2．抽象出当前系统的逻辑模型。分析系统的概念模型， 抽象出其本质的因素，排除次要因素，获得用数据流图 DFD 图等描述的当前系统的逻辑模型。 3．建立目标系统的逻辑模型。分析目标系统与当前系统 逻辑上的差别，从而进一步明确目标系统“做什么”，建 立目标系统的“逻辑模型”(修改后的数据流图DFD 图等)。 4．建立人机交互接口和其他必要的模型，确定各种方案 的成本和风险等级，据此对各种方案进行分析，选择其中 一种方案，建立完整的需求规约。 分析模型的结构如图3-4所示。
Y
用户和设计者是否满意
N
运行原型
是否放弃
Y
N
把原型作为 把原型作为应 应用系统 用系统开发的
软件工程导论第3章
2.访谈
访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍 然广泛使用的需求分析技术。 访谈有两种基本形式： 正式访谈：系统分析员将提出一些事先准备好的具体问题。 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题， 以鼓励被访问人员说出自己的想法。 调查表是当需要调查大量人员的意见时的一个十分有效的做法。 分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户， 以便向他们询问在分析调查表时发现的新问题。 在访问用户的过程中可以使用情景分析技术。情景分析技术的 用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而便于用户理解， 而且还可能进一步揭示出一些分析员目前还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这种技术能保证用户在 需求分析过程中始终扮演一个积极主动的角色。
（1） 数据对象
数据对象是对软件必须理解的复合信息的抽象。所谓 复合信息是指具有一系列不同性质或属性的事物，仅有单 个值的事物(例如，宽度)不是数据对象。 数据对象可以是外部实体(例如，产生或使用信息的任 何事物)、事物(例如，报表)、行为(例如，打电话)、事件 (例如，响警报)、角色(例如，教师、学生)、单位(例如，会 计科)、地点(例如，仓库)或结构(例如，文件)等。总之，可 以由一组属性来定义的实体都可以被认为是数据对象。 数据对象彼此间是有关联的，例如，教师“教”课程， 学生“学”课程，教或学的关系表示教师和课程或学生和 课程之间的一种特定的连接。
（4）需求验证 由软件开发者和用户一起来进行软件需求规格
说明的复审。确保需求规格说明可作为软件设计和最 终系统验收的依据。
二. 需求获取的常用方法
1. 建立联合分析小组 建立一个由用户、系统分析员和领域专家参加 的联合分析小组，密切合作，共同标识问题，提出 解决方案要素，商讨不同方案并指定基本需求。 这是一种面向团队的需求收集法，又称为简易 的应用规格说明技术。
软件工程导论-第3章_需求分析_(第五版)(张海藩编著)_a_百度文库
求互相矛盾。
(2) 完整性：需求必须是完整的，规格说明书应该包括用户需要的
每一个功能或性能。
(3) 现实性：指定的需求应该是用现有的硬件技术和软件技术基本
上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步 则很难做出预测，只能从现有技术水平出发判断需求的现实性。
(4) 有效性：必须证明需求是正确有效的，确实能解决用户面对的
成功来之不易
31%
（取消）
16.2%
（成功地完成）
53.8%
（受到挑战） Source: Standish Group
2
软件项目失败的原因
软件项目失败的最重要的五个主要原因：
需求不完整 缺少客户的参与 缺少资源 期望值过高 缺少高层的支持
0% 5% 10% 15%
3
需求错误的成本
4
软件需求的重要性： •软件需求分析是决定软件成功开发的一个关键因素
3.1.4 修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体 的了解，可以比较准确地估计系统的成本和进度，修 正以前制定的开发计划。
补充：与用户沟通获取需求的方法
3.2 与用户沟通获取需求的方法
需求获取的困难：
－用户通常并不真正知道自己希望计算机系统做什么 用户通常使用业务语言表达需求，开发人员缺乏相关 的领域知识和经验，难以准确理解这些需求 －不同的用户提出不同的需求，可能存在矛盾和冲突 管理者可能出于增加影响力的原因而提出特别的需求 －由于经济和业务环境的动态性，需求经常发生变更
图3.7 IPO图的一个例子图
模块编号:c.5.5.8
图3.7 IPO图的一个例子图
图3.8 改进的IPO图的形式
本书建 议使用 一种改 进的 IPO图 (也称 为IPO 表 )，
(2) 完整性：需求必须是完整的，规格说明书应该包括用户需要的
每一个功能或性能。
(3) 现实性：指定的需求应该是用现有的硬件技术和软件技术基本
上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步 则很难做出预测，只能从现有技术水平出发判断需求的现实性。
(4) 有效性：必须证明需求是正确有效的，确实能解决用户面对的
成功来之不易
31%
（取消）
16.2%
（成功地完成）
53.8%
（受到挑战） Source: Standish Group
2
软件项目失败的原因
软件项目失败的最重要的五个主要原因：
需求不完整 缺少客户的参与 缺少资源 期望值过高 缺少高层的支持
0% 5% 10% 15%
3
需求错误的成本
4
软件需求的重要性： •软件需求分析是决定软件成功开发的一个关键因素
3.1.4 修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体 的了解，可以比较准确地估计系统的成本和进度，修 正以前制定的开发计划。
补充：与用户沟通获取需求的方法
3.2 与用户沟通获取需求的方法
需求获取的困难：
－用户通常并不真正知道自己希望计算机系统做什么 用户通常使用业务语言表达需求，开发人员缺乏相关 的领域知识和经验，难以准确理解这些需求 －不同的用户提出不同的需求，可能存在矛盾和冲突 管理者可能出于增加影响力的原因而提出特别的需求 －由于经济和业务环境的动态性，需求经常发生变更
图3.7 IPO图的一个例子图
模块编号:c.5.5.8
图3.7 IPO图的一个例子图
图3.8 改进的IPO图的形式
本书建 议使用 一种改 进的 IPO图 (也称 为IPO 表 )，
软件工程导论第讲义3章需求分析
- 后台处理流程： 建模！解释后台处理的逻辑。 模型是用户方面的技术人员。好的模型对于系 统的扩展和改变至关重要。
2 原型法处理界面设计问题
在不少项目中，一旦用户对界面挑剔起来将会花 费大量时间。因此，在原型阶段，就应包括界面 设计的原则。从界面风格，易用性，友好化，用 户习惯等多方面达成一定规定，会对程序员在界 面设计上节省大量时间。
1 界面处理流程和后台业务处理流程是否正确。
- 界面处理流程： 界面是指用户面对的界面。 用户只有看到具体的软件界面，才会形成感性 的知识，才能对开发的系统提出具体要求，和 进一步的改进需求。才能理解我们推荐的解决 方案。另一方面，这也是检验PM对用户需求的 理解是否正确，能否做出符合要求的产品。
例如：大多数的动态网站，都是在客户初步的 需求基础上，先制作一个大体上能表现功能的 静态网站出来，然后客户根据这个静态网站提 出进一步的详细需求，开发便按照这个详细需 求来进行。
为了快速地构建和修改原型，通常使用下述3 种方法和工具：
(1) 第四代技术
第四代技术包括众多数据库查询和报表语言、 程序和应用系统生成器以及其他非常高级的 非过程语言。第四代技术使得软件工程师能 够快速地生成可执行的代码，它们是较理想 的快速原型工具。
3.1.3 软件需求分析的任务
一、综合需求
需求分类
功能需求 性能需求 环境需求
(1) 功能需求
• 系统做什么？ • 系统何时做什么？ • 系统何时及如何修改或升级？
(2) 性能需求
软件开发的技术性指标 例如：
• 存储容量限制 • 执行速度、相应时间 • 吞吐量
(3) 环境需求
• 硬件设备：机型、外设、接口、
优点：经济、易于管理；
可以快速将结果制表并分析
2 原型法处理界面设计问题
在不少项目中，一旦用户对界面挑剔起来将会花 费大量时间。因此，在原型阶段，就应包括界面 设计的原则。从界面风格，易用性，友好化，用 户习惯等多方面达成一定规定，会对程序员在界 面设计上节省大量时间。
1 界面处理流程和后台业务处理流程是否正确。
- 界面处理流程： 界面是指用户面对的界面。 用户只有看到具体的软件界面，才会形成感性 的知识，才能对开发的系统提出具体要求，和 进一步的改进需求。才能理解我们推荐的解决 方案。另一方面，这也是检验PM对用户需求的 理解是否正确，能否做出符合要求的产品。
例如：大多数的动态网站，都是在客户初步的 需求基础上，先制作一个大体上能表现功能的 静态网站出来，然后客户根据这个静态网站提 出进一步的详细需求，开发便按照这个详细需 求来进行。
为了快速地构建和修改原型，通常使用下述3 种方法和工具：
(1) 第四代技术
第四代技术包括众多数据库查询和报表语言、 程序和应用系统生成器以及其他非常高级的 非过程语言。第四代技术使得软件工程师能 够快速地生成可执行的代码，它们是较理想 的快速原型工具。
3.1.3 软件需求分析的任务
一、综合需求
需求分类
功能需求 性能需求 环境需求
(1) 功能需求
• 系统做什么？ • 系统何时做什么？ • 系统何时及如何修改或升级？
(2) 性能需求
软件开发的技术性指标 例如：
• 存储容量限制 • 执行速度、相应时间 • 吞吐量
(3) 环境需求
• 硬件设备：机型、外设、接口、
优点：经济、易于管理；
可以快速将结果制表并分析
第3章 需求分析
6
软 件 工 程
4. 出错处理需求
这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到 从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这 类错误并不是由该应用系统本身造成的。 在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一 个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。 我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖 自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键 部分，而且应该尽可能少。 3.7.6 故障处理 a. 内部故障处理 在开发阶段可以随即修改数据库里的相应内容。 b. 外部故障处理 对编辑的程序进行重装载时，第一次装载认为错，修改。第二次运 行，在需求调用时出错，有错误提示，重试。
(1)必须理解并描述问题的信息域，根据这条准则应该建 立数据模型。 (2)必须定义软件应完成的功能，这条准则要求建立功能 模型。 (3)必须描述作为外部事件结果的软件行为，这条准则要 求建立行为模型。 (4)必须对描述信息、功能和行为的模型进行分解，用层 次的方式展示细节。
12
第 3 章 需 求 分 析
据存储（可行性研究得到的高层数据流图）定义到元素级。
沿数据流图从输出端往输入端回溯着手分析。
第 3 章 需 求 分 析
图3.1 面向数据流自顶向下求精过程
15
3.2.3 简易的应用规格说明技术 软 件 工 简易的应用规格说明技术（面向团队的而求收集法）提倡用户 程 与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同
18
软 件 工 程
3.3.2 软件需求规格说明
通过需求分析除了创建分析模型之外，还应该写出软件 需求规格说明书，它是需求分析阶段得出的最主要的文档。 通常用自然语言完整、准确、具体地描述系统的数据要 求、功能需求、性能需求、可靠性和可用性要求、出错处理 需求、接口需求、约束、逆向需求以及将来可能提出的要求。 自然语言的规格说明具有容易书写、容易理解的优点，为大 多数人所欢迎和采用。 为了消除用自然语言书写的软件需求规格说明书中可能 存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题， 有些人主张用形式化方法描述用户对软件系统的需求，第4章 将简要地介绍形式化说明技术。
软 件 工 程
4. 出错处理需求
这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到 从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这 类错误并不是由该应用系统本身造成的。 在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一 个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。 我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖 自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键 部分，而且应该尽可能少。 3.7.6 故障处理 a. 内部故障处理 在开发阶段可以随即修改数据库里的相应内容。 b. 外部故障处理 对编辑的程序进行重装载时，第一次装载认为错，修改。第二次运 行，在需求调用时出错，有错误提示，重试。
(1)必须理解并描述问题的信息域，根据这条准则应该建 立数据模型。 (2)必须定义软件应完成的功能，这条准则要求建立功能 模型。 (3)必须描述作为外部事件结果的软件行为，这条准则要 求建立行为模型。 (4)必须对描述信息、功能和行为的模型进行分解，用层 次的方式展示细节。
12
第 3 章 需 求 分 析
据存储（可行性研究得到的高层数据流图）定义到元素级。
沿数据流图从输出端往输入端回溯着手分析。
第 3 章 需 求 分 析
图3.1 面向数据流自顶向下求精过程
15
3.2.3 简易的应用规格说明技术 软 件 工 简易的应用规格说明技术（面向团队的而求收集法）提倡用户 程 与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同
18
软 件 工 程
3.3.2 软件需求规格说明
通过需求分析除了创建分析模型之外，还应该写出软件 需求规格说明书，它是需求分析阶段得出的最主要的文档。 通常用自然语言完整、准确、具体地描述系统的数据要 求、功能需求、性能需求、可靠性和可用性要求、出错处理 需求、接口需求、约束、逆向需求以及将来可能提出的要求。 自然语言的规格说明具有容易书写、容易理解的优点，为大 多数人所欢迎和采用。 为了消除用自然语言书写的软件需求规格说明书中可能 存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题， 有些人主张用形式化方法描述用户对软件系统的需求，第4章 将简要地介绍形式化说明技术。
《软件需求分析》课件
2
需求分析
对收集到的需求进行分类、分析方法和验证。
3
需求规格说明
编写需求规格文档和需求规格说明书，并满足格式要求。
软件需求分析的工具和技术
用例图和用例描述
通过用例图和用例描述来描 述系统的功能和行为。
数据库图
使用数据库图来描述系统中 的数据结构和关系。
业务流程图
使用业务流程图来描绘系统 的业务流程和工作流程。
系统交互图
使用系统交互图来描述系统与用户或其他系统之 间的交互过程。
其他工具和技术
还有其他一些工具和技术可以用于辅助软件需求 分析，比如原型设计等。
软件需求分析的挑战和解决办法
1 需求不准确
通过与利益相关者密切合作，使用迭代的方 法来不断澄清和明确需求。
2 需求冲突
通过协商和妥协，以及优先级排序等方法来 解决需求之间的冲突。
《软件ቤተ መጻሕፍቲ ባይዱ求分析》PPT课 件
欢迎大家来到本次课程《软件需求分析》的PPT课件。在这个课程中，我们 将会深入探讨软件需求分析的核心内容和使用的工具和技术。
引言
在本节中，我们将介绍什么是软件需求分析、为什么进行软件需求分析以及 软件需求分析的重要性。
软件需求分析流程
1
需求收集
通过收集多渠道的需求来源，并编写需求文档。
3 需求变更
建立灵活的变更管理机制，通过评估和影响 分析来控制需求变更。
4 需求管理
建立完善的需求管理过程和工具，确保需求 的跟踪、审批和变更控制。
总结
通过本次课程，我们了解了软件需求分析的意义、流程、工具和技术，以及面临的挑战和解决办法。
参考资料
书籍 报告 文 网站
软件工程导论第五版张海藩第03章-需求分析
第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 需求规定
建模方法
在过去的数年中，人们提出了许多种分析建模的方法，其中两种 在分析建模领域占有主导地位：
第一种是结构化分析 (Structured Analysis，SA)，70年代末由 DeMarco等人提出，这是传统的建模方法。该方法不是被所有的使用 者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发 展了超过30年的一个混合物。
2） 项目相关人员用自己的语言表达需求，这些 语言包含很多工作中的专业术语和专业知识。系统分 析员没有这些知识和经验，而他们又必须了解这些需 求。
3）不同的项目相关人员有不同的需求，可能以 不同的方式表达，分析人员必须发现所有潜在的需求 资源，而且能发现这些需求的相容或冲突之处。
4）经济和业务环境决定了分析是动态的，需求 在分析过程中会发生变更。个别需求的重要程度会改 变，新的需求会从新的项目相关人员那里得到。
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 需求规定
建模方法
在过去的数年中，人们提出了许多种分析建模的方法，其中两种 在分析建模领域占有主导地位：
第一种是结构化分析 (Structured Analysis，SA)，70年代末由 DeMarco等人提出，这是传统的建模方法。该方法不是被所有的使用 者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发 展了超过30年的一个混合物。
2） 项目相关人员用自己的语言表达需求，这些 语言包含很多工作中的专业术语和专业知识。系统分 析员没有这些知识和经验，而他们又必须了解这些需 求。
3）不同的项目相关人员有不同的需求，可能以 不同的方式表达，分析人员必须发现所有潜在的需求 资源，而且能发现这些需求的相容或冲突之处。
4）经济和业务环境决定了分析是动态的，需求 在分析过程中会发生变更。个别需求的重要程度会改 变，新的需求会从新的项目相关人员那里得到。
《软件需求分析》第3章 需求获取课件
分的时间与开发人员进行交流和讨论 ； 2. 有时用户希望通过简单的方法和说明，或者
通过简单回答开发人员的询问后，软件开发 人员就能清楚地理解他们的需求，而不需要 花费太多的时间进行讨论；
2023/6/25
15
3.4实地收集需求信息
3. 用户和开发人员都只考虑自己的利益；如： 有些用户由于缺乏使用计算机的经验，导致 产生畏难情绪；有些用户认为开发软件系统 自己的关系不大，对待需求信息的收集工作 采取消极的态度。
4
3.2确定项目的目标和范围
此阶段的基本任务是根据项目目标把项目 相关人员定位到一个共同的和明确的方向上， 并决定软件系统的范围。
项目的范围与项目的目标特别是软件系统 的目标需求是密切相关的。
2023/6/25
5
3.2确定项目的目标和范围
在收集目标需求时，目标需求会来源于各 个不同的人，这些人对要开发的软件系统及该 系统最终能为用户或客户提供哪些价值有比较 清楚的了解。
理。
10)尊重需求工程中开发人员采用的流程（过程）。
2023/6/25
10
3.3确定调查对象
软件需求可来自与各个方面，而且用户类 也不一定都是指人。有时也可以把其它应用系 统或计算机硬件设备和接口等视为附加的用户 类成员，这样就可确定软件系统与哪些外部应 用系统或计算机硬件相关的需求。这就是说需 求信息来源除了来自用户类外，还可来自于其 它方面。
7
3.3确定调查对象
软件系统面临的用户是很多的，而这些用 户由于所在的部门、职责和掌握的知识不同而 存在差异，为了避免忽视和遗漏某些用户的情 况，可以根据用户的某些方面将用户分类。
2023/6/25
8
3.3确定调查对象
在将用户分类后，在分类的基础上进一步 寻找每类用户的代表或联络人，这些人代表了 一个特定的用户类，并可充当该用户类与开发 人员之间的“窗口”。
通过简单回答开发人员的询问后，软件开发 人员就能清楚地理解他们的需求，而不需要 花费太多的时间进行讨论；
2023/6/25
15
3.4实地收集需求信息
3. 用户和开发人员都只考虑自己的利益；如： 有些用户由于缺乏使用计算机的经验，导致 产生畏难情绪；有些用户认为开发软件系统 自己的关系不大，对待需求信息的收集工作 采取消极的态度。
4
3.2确定项目的目标和范围
此阶段的基本任务是根据项目目标把项目 相关人员定位到一个共同的和明确的方向上， 并决定软件系统的范围。
项目的范围与项目的目标特别是软件系统 的目标需求是密切相关的。
2023/6/25
5
3.2确定项目的目标和范围
在收集目标需求时，目标需求会来源于各 个不同的人，这些人对要开发的软件系统及该 系统最终能为用户或客户提供哪些价值有比较 清楚的了解。
理。
10)尊重需求工程中开发人员采用的流程（过程）。
2023/6/25
10
3.3确定调查对象
软件需求可来自与各个方面，而且用户类 也不一定都是指人。有时也可以把其它应用系 统或计算机硬件设备和接口等视为附加的用户 类成员，这样就可确定软件系统与哪些外部应 用系统或计算机硬件相关的需求。这就是说需 求信息来源除了来自用户类外，还可来自于其 它方面。
7
3.3确定调查对象
软件系统面临的用户是很多的，而这些用 户由于所在的部门、职责和掌握的知识不同而 存在差异，为了避免忽视和遗漏某些用户的情 况，可以根据用户的某些方面将用户分类。
2023/6/25
8
3.3确定调查对象
在将用户分类后，在分类的基础上进一步 寻找每类用户的代表或联络人，这些人代表了 一个特定的用户类，并可充当该用户类与开发 人员之间的“窗口”。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
A) True
B) False
3：The best way to conduct a requirements validation review is to
A) examine the system model for errors
B) have the customer look over the requirements
C) identify, control, and track requirements changes
D) none of the above
14：Requirements engineering is a generic process that does not vary from one software project to another.
A) What will be the economic benefit from a good solution?
B) Who is against this project?
C) Who will pay for the work?
D) Who will use the solution?
17：Use-case actors are always people, never system devices.
A) True
B) False
8：The result of the requirements engineering elaboration task is an analysis model that defines which of the following problem domain(s)?
A) True
B) False
2：It is relatively common for different customers to propose conflicting requirements, each arguing that his or her version is the right one.
A) True
B) False
15：In requirements validation the requirements model is reviewed to ensure its technical feasibility.
A) True
B) False
16：Which of the following is not one of the context-free questions that would be used during project inception?
A) True
B) False
窗体顶端
1818：The work products produced during requirement elicitation will vary depending on the
A) size of the budget
B) size of the product being built
A) information
B) functional
C) behavioral
D) all of the above
9：In collaborative requirements gathering, the facilitator
A) cannot be a member of the software team
A) True
B) False
13：The use of traceability tables helps to
A) debug programs following the detection of run-time errors
B) determine the performance of algorithm implementations
A) exciting
B) expected
C) mandatory
D) normal
正确答案:C窗体底端
窗体顶端
二、主观题
C) send them to the design team and see if they have any concerns
D) use a checklist of questions to examine each requirement
4：Which of following is not a UML diagram used creating a system analysis model?
A) True（备注：应该是设计模型）
B) False
11：A stakeholder is anyone who will purchase the completed software system under development.
A) True
B) False
正确答案:B
12：The nature of collaboration is such that all system requirements are defined by consensus of a committee of customers and developers.
B) cannot be a customer
C) controls and facilitates the process
D) must be an outsider
10：Analysis patterns facilitate the transformation of the analysis model into a design model by suggesting reliable solutions to common problems.
C) element software architecture
D) time required for system simulation
7：Developers and customers create use-cases to help the software team understand how different classes of end-users will use functions.
C) software process being used
D) stakeholders needs
正确答案:B
正确答案:B
19：Which of the following is not one of the requirement classifications used in Quality Function Deployment (QFD)?
A) True
B) False
6：The system specification describes the
A) Function, performance and constraints of a computer-based system
B) implementation of each allocated system
第3章软件需求分析
窗体顶端
一、客观题
1：The job of the requirements engineer is to categorize all stakeholder information in a way that allows decision makers to choose an internally consistent set of requirements.
A) activity diagram
B) class diagram
C) dataflow diagram
D) state diagram
5：In win-win negotiation, the customer\'s needs are met even though the developer\'s need may not be.
B) False
3：The best way to conduct a requirements validation review is to
A) examine the system model for errors
B) have the customer look over the requirements
C) identify, control, and track requirements changes
D) none of the above
14：Requirements engineering is a generic process that does not vary from one software project to another.
A) What will be the economic benefit from a good solution?
B) Who is against this project?
C) Who will pay for the work?
D) Who will use the solution?
17：Use-case actors are always people, never system devices.
A) True
B) False
8：The result of the requirements engineering elaboration task is an analysis model that defines which of the following problem domain(s)?
A) True
B) False
2：It is relatively common for different customers to propose conflicting requirements, each arguing that his or her version is the right one.
A) True
B) False
15：In requirements validation the requirements model is reviewed to ensure its technical feasibility.
A) True
B) False
16：Which of the following is not one of the context-free questions that would be used during project inception?
A) True
B) False
窗体顶端
1818：The work products produced during requirement elicitation will vary depending on the
A) size of the budget
B) size of the product being built
A) information
B) functional
C) behavioral
D) all of the above
9：In collaborative requirements gathering, the facilitator
A) cannot be a member of the software team
A) True
B) False
13：The use of traceability tables helps to
A) debug programs following the detection of run-time errors
B) determine the performance of algorithm implementations
A) exciting
B) expected
C) mandatory
D) normal
正确答案:C窗体底端
窗体顶端
二、主观题
C) send them to the design team and see if they have any concerns
D) use a checklist of questions to examine each requirement
4：Which of following is not a UML diagram used creating a system analysis model?
A) True（备注：应该是设计模型）
B) False
11：A stakeholder is anyone who will purchase the completed software system under development.
A) True
B) False
正确答案:B
12：The nature of collaboration is such that all system requirements are defined by consensus of a committee of customers and developers.
B) cannot be a customer
C) controls and facilitates the process
D) must be an outsider
10：Analysis patterns facilitate the transformation of the analysis model into a design model by suggesting reliable solutions to common problems.
C) element software architecture
D) time required for system simulation
7：Developers and customers create use-cases to help the software team understand how different classes of end-users will use functions.
C) software process being used
D) stakeholders needs
正确答案:B
正确答案:B
19：Which of the following is not one of the requirement classifications used in Quality Function Deployment (QFD)?
A) True
B) False
6：The system specification describes the
A) Function, performance and constraints of a computer-based system
B) implementation of each allocated system
第3章软件需求分析
窗体顶端
一、客观题
1：The job of the requirements engineer is to categorize all stakeholder information in a way that allows decision makers to choose an internally consistent set of requirements.
A) activity diagram
B) class diagram
C) dataflow diagram
D) state diagram
5：In win-win negotiation, the customer\'s needs are met even though the developer\'s need may not be.