5.3 需求分析

需求分析

软件需求
- 定义
- 分类
- 练习题
需求工程

考试大概3分

软件需求

定义

软件需求：是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
IEEE中的定义是：软件需求指用户解决问题或达到目标所需要的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
需求来源：
- 可以来自于用户（实际的潜在的）、用户的规约、应用领域的专家、相关的技术标准和法规；
- 可以来自于原有的系统、原有系统的用户、新系统的潜在用户；
- 甚至还可以来自于竞争对手的产品。

练习题

某软件公司正在承担开发一个文字处理器的任务。在需求分析阶段，公司的相关人员整理出一些相关的系统需求其中，"找出文档中的拼写错误并提供一个替换项列表来供选择替换拼错的词"属于()，"显示提供替换词的对话框以及实现整个文档范围的替换"属于（)，"用户能有效地纠正文档中的拼写错误"属于()。

A,业务需求 B.用户需求 C,功能需求 D.性能需求

A,业务需求 B.用户需求 C.功能需求 D.性能需求

答案B C A

需求工程

需求工程：是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。需求工程可以细分为需求获取、需求分析（包括系统建模）、需求规约、需求验证以及需求管理 5个阶段。
- 需求开发 ：包括需求获取、需求分析、编写规约（系统规格说明书）和需求验证4个阶段。
- 需求管理：通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。
需求开发的4个阶段：
- 在需求开发阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际的用户任务和目标，以及这些任务所支持的业务需求。
- 同时还包括分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型，以及对需求进行评审等工作。

需求获取

需求获取：是一个确定和理解不同的项目干系人的需求和约束的过程。在需求获取的过程中，主要解决需求调查的问题。要想做好需求调查，必须清楚地了解三个问题。
- What:应该搜集什么信息。
- Where:从什么地方搜集这些信息。
- HOW:用什么机制或者技术来搜集这些信息。
常见的需求获取方式有：用户访谈、问卷调查、采样 、情节串联版、联合需求计划等。
- 用户访谈：一对一进行访谈，适合于针对有代表性的用户。其形式分为结构化和非结构化两种。
- 问卷调查：设计问题、制作成用户调查问卷、下发填写、整理分析。适合用户面广、用户需要灵活时间进行回馈。
- 采样：采用统计分析技术，从目标总体中选择出样本集的过程。可以是随机抽样，也可以是非随机抽样。适合用于大量用户信息或者数据信息采集分析，最终得出需求的场景。
- 情节串联板：一系列图片，通过这些图片来讲故事。
- 联合讨论会：通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。
- 需求记录技术：任务卡片、场景说明、用户故事等。

练习题

需求获取是确定和理解不同的项目干系人的需求和约束的过程，需求获取是否科学、准备充分，对获取出来的结果影响很大。在多种需求获取方式中，()方法具有良好的灵活性，有较宽广的应用范围，但存在获取需求时信息量大、记录较为困难、需要足够的领域知识等问题。()方法基于数理统计原理，不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户并可以减少数据收集偏差。()方法通过高度组织的群体会议来分析企业内的问题，并从中获取系统需求。

A用户访谈 B.问卷调查 C.联合需求计划 D采样

A用户访谈 B问卷调查 C,联合需求计划 D采样

A用户访谈 B.问卷调查 C,联合需求计划 D.采样

答案A D C

需求分析

需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。需求分析人员需要把杂乱无章、真假难辨的用户要求和期望转化为真正的用户需求，最终再将用户需求转化为系统需求，形成最终的需求规约（需求规格说明书）。
需求分析：逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，别除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的模型)。
需求分析的任务：
- 绘制系统上下文范围关系图
- 创建用户界面原型
- 分析需求的可行性
- 确定需求的优先级
- 为需求建立模型
- 创建数据字典
- 使用QFD(质量功能部署)
目前，已存在的多种需求分析方法引用了不同的分析策略，常用的分析方法有以下两种：
- 面向数据流的结构化分析方法(SA)。
- 面向对象的分析方法(OOA)。
结构化分析方法的特点是：自顶向下、逐步分解、分析的核心是数据字典。
结构化分析应该建立三种模型：数据模型、功能模型、行为模型：
- 数据模型 ：常用实体关系(E-R)图描述实体、属性，以及实体间的关
  系；
- 功能模型：常用数据流图(DFD data flow diagram),从数据传输加工的角度，用图形符号描述数据在系统间的传递情况；DFD和QFD不要记错了
- 行为模型 ：又称状态模型，常用状态转换图(STD state transform diagram)描述系统状态和引起系统状态转换的事件，表示系统行为，指出作为特定事件的结果将执行哪些动作

状态转化图

数据流图DFD

数据流图(Data Flow Diagram,简称DFD):描述数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能建模，数据流图相关概念示例如下：
数据流图：是可以分层的，根据层级数据流图分为顶层数据流图、中层数据流图和底层数据流图 。除顶层数据流图外，其他数据流图从零开始编号。
- 顶层数据流图只含有一个加工表示整个系统；输出数据流和输入数据流为系统的输入数据和输出数据，表明系统的范围，以及与外部环境的数据交换关系。
- 中层数据流图是对父层数据流图中某个加工进行细化，而它的某个加工也可以再次细化，形成子图；中间层次的多少，一般视系统的复杂程度而定。
- 底层数据流图 是指其加工不能再分解的数据流图，其加工称为"原子加工"。

顶层数据流图

0层数据流图

1层数据流图

练习题

结构化分析方法中，数据流图中的元素在()中进行定义。

A,加工逻辑

B,实体联系图

C.流程图

D.数据字典

答案：D

下列关于结构化分析方法的数据字典加工逻辑的叙述中，不正确的是()。

A,对每一个基本加工，应该有一个加工逻辑

B.加工逻辑描述输入数据流变换位输出数据的加工规则

C.加工逻辑必须实现加工的数据结构和算法

D,结构化语言，判定树和判定表可以用来表示加工逻辑

答案：C

绘制分层数据流图(DFD)时需要注意的问题中，不包括(）。

A,给图中的每个数据流、加工、数据存储和外部实体命名

B,图中要表示出控制流

C.一个加工不适合有过多的数据流

D,分解尽可能均匀

答案：B

需求规约

软件需求规约：也叫需求定义、软件需求规格说明书SRS,是需求分析任务的最终产物，通过建立完整的信息描述详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。
需求规约作为用户和开发者之间的一个协议，在之后的软件工程各阶段发挥重要的作用。
软件需求规约中通常包含以下内容：
- 引言。引言陈述软件目标，在基于计算机的系统语境内进行描述。
- 信息描述。信息描述给出软件必须解决的问题的详细描述，记录信息内容、信息流和信息结构。
- 功能描述。功能描述用来描述解决问题所需要的每个功能。其中包括为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。
- 行为描述。行为描述用于描述作为外部事件和内部产生的控制特征的软件操作。
- 校验标准。检验标准描述检验系统成功的标志，即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。检验标准是"确认测试"的基础。
- 参考书目。参考书目包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献和标准。
- 附录。附录包含了规约的补充信息，表格数据、算法的详细描述、图表和其他资料。

需求定义方法

严格定义也称为预先定义，需求的严格定义建立在以下的基础假设之上；所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形（或文字）可以充分体现最终系统。
原型方法，迭代的循环型开发方式 ，需要注意的问题：并非所有的需求都能在系统开发前准确的说明。项目干系人之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。特点：需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

需求验证

需求验证：也称为需求确认，目的是与用户一起确认需求无误。对需求规约进行评审和测试，包括两个步聚：
- 需求评审：正式评审和非正式评审。
- 需求测试：设计概念测试用例。
需求验证作为需求开发阶段工作的复查手段，其目的是要检验需求功能的正确性、完整性和清晰性 ，是否能够反映用户的意愿，由于需求的变化往往使系统的设计和实现也跟着改变，所以由需求问题引起系统变更的成本比修改设计或代码错误的成本高得多 。因此，为保证软件需求定义的质量，评审应指定专门的人员负责，并按规程严格进行 。除分析人员之外，还要有用户，开发部门的管理者，软件设计、实现、测试的人员参加。
需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。
需求验证也不可能发现所有的需求问题。在需求验证之后，对遗漏的补充以及对错误理解的更正是不可避兔的，因此需要进行需求管理。
需求验证内容：
1. 系统定义的目标是否与用户的要求一致。
2. 系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求。
3. 被开发项目的数据流与数据结构是否确定且充足。
4. 主要功能是否已包括在规定的软件范围之内，是否都已充分说明。
5. 设计的约束条件或限制条件是否符合实际。
6. 开发的技术风险是什么。
7. 是否详细地制定了检验标准，它们能否对系统定义进行确认。

需求管理

软件需求管理：是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求 的活动，对需求工程所有相关活动的规划和控制。换句话说，需求管理就是一种获取、组织并记录系统需求的系统化方案 ，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。
在需求管理中，每个需求被赋予唯一的标识符 ，一旦标识出需求，就可以为需求建立跟踪表，每个跟踪表标识需
求与其他需求或设计文档、代码、测试用例的不同版本间的关系。
- 特征跟踪表，记录需求如何与产品或系统特征相关联；
- 来源跟踪表，记录每个需求的来源；
- 依赖跟踪表，描述需求间如何关联等。
这些跟踪表可以用于需求跟踪 。在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性 ，确保所有的实现是以用户需求为基础，所有的输出符合用户需求，并且全面覆盖了用户需求。

版本控制

版本控制：使项目团队和用户达成共识，定义需求基线。通过了评审的需求规约（需求说明书）就是需求基线 ，下次如果需求变更需求，就需要安装流程来一步步进行。

需求跟踪

需求跟踪有两种方式：正向跟踪和逆向跟踪 。
- 正向跟踪以用户需求为切入点 ，检查《需求规约》中的每个需求是否都能在后继工作产品中找到对应点；简单点说，就是用户原始需求是否都实现了。
- 逆向跟踪检查设计文档、代码、测试用例等工作产品是否都能在《需求规约》中找到出处。简单点说，就是软件实现的是否都是用户要求的
状态跟踪
- 整个项目过程中，要始终跟踪需求状态即变更情况

变更控制

变更控制：主要关心需求变更中的需求风险管理 ，带有风险的做法有：无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。
变更产生的原因：外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。
变更控制委员会CCB:也称为配置控制委员会，其任务时对建议的配置项变更做出评价、审批，以及监督已经批准变更的事实。
变更控制的内容有：
- 需求变更需要经过正式评估来决定是否批准
- 保持项目计划与需求的同步
- 以可控制的方式将需求变更融入项目中
- 估计变更需求产生的影响，并协商新的约定

练习题

()是关于需求管理正确的说法。

A.为达到过程能力成熟度模型第二级，组织机构必须具有3个关键过程域

B.需求的稳定性不属于需求属性

C.需求变更的管理过程遵循变更分析和成本计算、问题分析和变更描述、变更实现的顺序

D.变更控制委员会对项目中任何基线工作产品的变更都可以做出决定

答案D

需求分析

软件需求

定义

分类

练习题

需求工程

需求获取

练习题

需求分析

状态转化图

数据流图DFD

顶层数据流图

0层数据流图

1层数据流图

练习题

需求规约

需求定义方法

需求验证

需求管理

版本控制

需求跟踪

变更控制

练习题