携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第7天，点击查看活动详情
需求规格说明
需求获取：目标是得到用户需求——收集需求信息 需求分析：目标是更深刻的理解用户需求——界定能够让用户满意的解决方案准则 需求规格说明：目标是定义用户需求——准确描述需求及其解决方案
需求规格说明文档类型：
需求规格说明文档的描述手段：
非形式化：自然语言、限制性文本
半形式化：结构化文本（伪码/结构化英语）、模型语言（图、表…）
形式化：形式化语言（数学语言：BNF，Z…）
优秀需求规格说明文档的特性： 完备性、一致性、根据重要性和稳定性分级、可修改、可跟踪
1.系统需求开发的结果最终会写入（ 系统需求规格说明）。
2.项目的前景和范围文档、用户需求文档都被视为属于（ 用户文档），重点都是用户的现实世界。
3.系统需求规格说明文档、软件需求规格说明文档、硬件需求规格说明文档、接口需求规格说明文档和人机交互文档一起被用于系统开发的目的，都被认为是（开发文档）。
4.下列（ C）不是需求规格说明文档的读者。
A、项目管理者
B、编程人员
C、销售商
D、律师
5.编写需求规格说明文档的意义（ABCD）
A、需求规格说明文档可以成为各方人员之间有关软件系统的协议基准。
B、需求规格说明文档可以成为项目开发活动的一个重要依据。
C、在需求规格说明文档的编写过程 中，可以尽早的发现和减少可能的需求错误，从而减少项目的返工，降低项目的工作量。
D、需求规格说明文档可以成为有效的智力资产。
6.编写需求规格说明文档所使用的语言类型有（非形式化语言、半形式化语言、形式化语言）。
7.【判断题】软件需求规格说明文档是对部分系统功能分配给软件部分的详细描述。（×）
8.【判断题】人机交互文档是对整个系统功能中需要进行人机交互部分的详细描述。（√）
9.【判断题】需求规格文档化的目标是交流。（√）
需求验证
验证（Validation）与确认（Verification） 一方面，它要确保正确地得到需求（需求验证）得到足以作为软件创建基础的需求； 另一方面，它要确保得到正确的需求（需求确认），得到能够准确反映用户意图的需求。
需求验证活动的四个步骤： 需求验证普遍存在于需求开发活动中
1、在需求获取中：获得的用户需求是否正确和充分的支持业务需求？
2、在需求分析中：建立的分析模型是否正确的反映了问题域特性和需求？细化的系统需求是否充分和正确的支持用户需求？
3、需求规格说明：需求规格说明文档是否组织良好、书写正确？需求规格说明文档内的需求是否充分和正确的反映了涉众的意图？需求规格说明文档是否可以作为后续开发工作（设计、实现、测试等等）的基础？
4、需求验证：是指在需求规格说明完成之后，对需求规格说明文档进行的验证活动。
需求验证常见的方法； 需求评审、原型与模拟、开发测试用例、用户手册编制、利用跟踪关系和自动化分析。
评审过程的6个阶段： 1.规划阶段 2.总体部署阶段 3.准备阶段 4.评审会议阶段 5.返工阶段 6.跟踪阶段
评审的类型： 审查（最为严格）、小组评审（轻型审查）、走查、轮查、临时评审（最不正式）
1.在大多数情况下，需求都是在静态的方式下被加以验证。那么对复杂的动态行为就需要使用模拟或原型方法来加以验证。
2.评审的检查方法有自由方法、检查清单、缺陷、功能点、视角、场景和逐步提升。
3.【判断题】 需求验证活动同样普遍存在于需求分析过程中。（ ×）
4.【判断题】需求验证是需求工程中最后一个活动。（ ×）
5.需求验证并不是一个可以一次结束的活动，它可能需要多次、反复地执行验证。（ √）
6.在大多数情况下，需求都是在静态的方式下被加以验证。那么对复杂的动态行为就需要使用原型或模拟方法来加以验证。 ( √)
7.审查类型中最正式评审类型是轮查。（×）
8.验证是贯穿于整个软件生命周期的。（ √）
9.基于场景方法也是需求评审当中常用的一种检查方法。（√）
10.需求验证和需求确认一样，都能确保得到正确的需求。（ ×）
