1 需求分析的任务是什么。需求包含的内容

任务：用户和软件人员双方一起来充分地理解用户的要求，并把双方共同的理解明确地表达成一份书面文档—需求说明书

内容：功能需求和非功能需求

2 需求获取来源有哪些？

• 客户或用户
• 标准
• 法律或政策
• 系统或过程文档
• 相关领域专家

3 需求具体包含的哪些方面的内容。

功能需求、性能需求、用户需求、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求以及其他非功能性要求。

4 需求获取有哪些手段。

• 用户面谈
• 需求专题讨论会
• 调查问卷
• 现场考察
• 原型化方法
• 基于用例的方法

5 需求报告的作用是什么？

• 作为用户和软件人员之间的合同，为双方相互了解提供基础
• 反映出问题的结构，可以作为软件人员进行设计和编写的基础
• 作为验收的依据，即作为选取测试用例和进行形式验证的依据

6 需求报告的主要内容有哪些？

• 介绍
• 总体描述
• 外部接口需求
• 用例
• 非功能需求
• 其他需求
• 全局功能定义（可选）

Ps：不应该包括在SRS中的内容：

• 项目开发计划：诸如成本、人员、进度、工具、方法等
• 产品保证计划：诸如配置管理、验证与测试、质量保证等
• 软件设计细节：需求通常用于表达“做什么”，而不描述“如何做”。

7 写作技术文档的注意事项。

• 简洁：保持语句和段落的简短；
• 一致：上下文用语一致，陈述风格应该具有一致的样式。
• 具体：系统必须…；或者；用户必须…要紧跟着一个行为动作或可观察的结果。
  eg：计算过程中出现除零错误时，系统必须给出提示信息（不好！不具体）；
  计算过程中出现除零错误时，系统必须立即弹出对话框显示该错误，并进行声音提示（好！）。
• 必须避免模糊的，主观的术语，减少不确定性
  eg：用户友好、容易、简单、美观、迅速、有效、支持、许多、最新技术、优越的、可接收的和健壮的
• 避免使用比较性词汇
  eg：提高、最大化、最小化、最佳化。
  定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值
• 不应该把多个需求集中在一个冗长的叙述段落中
  eg：务必记住不要在需求说明中使用“和/或”，“等等”之类的连词（这个等，对于测试人员来说就是灾难…)

8 对需求报告做评审检查的时候，应该从那几个基本方面进行评审（需求文档的质量属性有哪些）？

作为需求分析阶段的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。
质量属性指非功能要求，软件需求规格说明书的质量特性包括正确性、无二义性、完整性、可验证性、一致性。

9 如何确保需求规格说明书的质量（验证需求的方法有哪些）？

需求验证是检验需求能否满足客户的意愿。

• 需求评审：由不同代表（如分析员、客户、设计人员、测试人员）组成的评审小组以会议形式对需求进行系统性分析。
• 原型评价：客户和用户在一个可运行的系统上实际检验系统是否符合他们的真正需要。
• 测试用例生成：通过设计具体的测试方法，发现需求种的许多问题。

10 需求建模时，除了可以使用数据流图数据字典之外，还有哪些需求建模手段？

• 实体联系方法（E-R图）
• 状态变迁图和状态迁移表
• 判定表和判定树
• UML建模工具

Ps：加工逻辑描述工具的选择
a.不太复杂的判断逻辑，使用判断树比较好；
b.复杂的判断逻辑，使用判断表比较好；
c.若一个处理逻辑既包含了一般的顺序执行动作，又包含了判断或循环逻辑，则使用结构化语言比较好。

11 判定表包含哪些要素？（要求：判定表要会画，判定树要能读懂）

一张判定表通常由四部分组成，：左上部列出的是所有的条件，左下部为所有可能的操作，右上部分表示各种条件组合的一个矩阵，右下部分是对应于每种条件组合应有的操作。

12 需求跟踪矩阵的内容是什么？解决什么问题？

内容：需求跟踪矩阵（ Requirement tracking matrix ，RTM ）是一种主要管理需求变更和验证需求是否得到了实现的有效工具，是一种把产品需求从其来源连接到能满足需求的可交付成果的一种表格(需求→生产制造→可交付成果)，借助RTM，可以跟踪每个需求的状态。
解决问题：
（1） 在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具，如果不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。
（2） RTM也是验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态：是否设计了，是否实现了，是否测试了。

13 什么是SA建模方法，SA建模图？

定义：
结构化分析方法（Structured Analysis，简称SA方法）是70年代中期提出的一种面向数据流、自顶向下、逐步求精进行需求分析的方法。

适用情况：
结构化分析方法适用于分析大型的数据处理系统，特别适用于企事业管理系统。

结构化分析方法通常与设计阶段的结构化设计方法（Structured Designed，简称SD方法）衔接起来使用。

过程指导：

• 建立系统的功能模型
  利用数据流图（Data Flow Diagram，DFD）将大问题分割成若干个小问题，采用分层的数据流图，先建立系统环境图（顶层），再逐步求精。
• 建立数据字典
  采用结构化英语，小说明，补充材料等列出。

步骤：
理解￫获得具体模型￫抽象出逻辑模型

SA主要针对数据处理领域，因此，系统分析的侧重点在于功能分析和数据分析，而行为分析使用得较少。

模型构成元素分析：

• 数据字典(DD)
  模型核心，包含了所有数据对象的描述的中心库。
• E-R图(ERD)
  表示数据对象以及相互的关系，用于数据建模。
• 数据流图(DFD)
  指明数据在系统中移动时如何被变换;
  描述对数据流进行变换的功能;
  DFD中每个功能的描述包含在加工规约(小说明)。
  用于功能建模。
• 状态变迁图(STD)
  指明作为外部事件的结果,系统将如何动作。用于行为建模。

14 补充

需求分析的过程
（1）调查研究
（2）分析与综合
（3）书写需求分析的文档
（4）评审
需求分析的过程步骤

逻辑模型与物理模型

需求分析的具体任务总结
（1）确定软件系统的综合需求
（2）分析系统的数据需求
（3）导出软件系统的逻辑模型
（4）修正系统开发计划
（5）开发原型系统
（6）验证软件需求分析的正确性
（7）编写软件需求规格说明书

软件需求规格说明书
SRS（Software Requirement Specification）
需求规格说明精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。

软件需求规格说明书的质量特性：
正确性：需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正需求。
无二义性：需求规格说明中的描述对于所有人都只能有一种明确统一的解释。
完整性：需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息。
可验证性：需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。
一致性：需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等。

什么是Checklist
Checklist是用于检查的一系列条目。之所以需要 Checklist，是因为人们的记忆会有疏忽，可能遗漏一些需要注意的事项，还因为人们的经验和水平有限，能够思考到的程度有差异，借助 Checklist 可以帮助我们做必要的检查。