《软件工程》第八章——需求获取

8.1 需求工程师

需求分析是软件工程中的重要步骤，是决定软件项目成败的关机影响因素之一。
软件和系统需求的获取、建模、分析、验证和管理（获取技术、分析方法、建模方法）

1. 要注意将问题的分析和解决方案的生成区别开来；
2. 要根据软件项目本身的规模、人员的技能、客观的条件、项目的成本来选择合适的需求获取技术和建模方法，选择最合理的软件系统设计方案。

8.1.1 当代的需求工程师

1. 分析问题和解决问题的能力
2. 人际沟通及交流能力
3. 软件工程知识和技能
4. 应用领域有关知识
5. 书面语言组织和表达能力
6. ……

8.1.2 优秀需求工程师的目标

1. 识别错误假设
2. 确保一致性
3. 提升依从性
4. 减少彼此误解
5. 提高支持速度和效率
6. 提升客户满意度
7. 撰写优质需求文档

8.1.3需求分析师七宗罪

1. 干扰
2. 沉默
3. 过度规约
4. 矛盾
5. 含糊
6. 向前引用
7. 不切实际也一厢情愿

8.2 需求定义

8.2.1什么是需求

**“需求”**是对外可见的系统特征。

“需求管理”有三项任务：

• 学习——需求获取
• 剪枝——需求优选
• 文档化——撰写需求规格说明书

需求，是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求将作为系统开发，测试，验收，提交的正式文档依据。

每一个“人造物”都是一个内部环境与外部环境的“接口”。这里内部环境指人造物本身的设计组成。外部环境指人造物的周遭及其作用环境。对这个接口的描述既是需求。

8.2.2 需求描述的难点

需求描述的难点和挑战就在于连接应用领域现象与机器领域现象的桥梁，要从应用领域的固有性质和用户待解决的需求描述转化为可以用计算机软件实现的系统行为的描述。

8.2.3需求的内容

• 需求是系统为慢走客户期望的目标而完成的行为
• 需求要体现对问题领域的清晰理解
• 给出系统的使用场景饿上下文

8.2.4 在定义需求的时候

将问题和解决方案分开，建立单独的问题描述文档：

• 深入地剖析表面上的问题，得到真正要解决地问题
• 将问题描述提交给干系人进行讨论
• 按问题描述选择候选设计方案
• 问题描述作为测试用例地来源
  
  
• 领域性质：无论系统存在与否均存在的应用领域的性质。
• 需求：由系统的存在而使能的应用领域性质。
• 规约描述：面熟系统为满足需求而应具有的行为。
• 需求证明的标准： 1. 运行在某台机器上的程序满足规约描述；
  2.针对给定的领域性质，规约描述满足需求。
• 需求验证的标准： 1. 是否已发现所有重要需求？
  2.是否已发现所有有关的领域性质？

8.2.5实例

8.7撰写需求文档

8.7.1 软件需求规格说明

• 是具有一定法律效力地合同文档
• 清楚地描述软件在什么情况下，需要做什么，以及不能做什么
• 以输入/输出、输入到输出之间的转换方式来描述功能性需求
• 描述经过干系人磋商达成共识的非功能性需求
• 一般参考需求定义模板，覆盖标准模板中定义的所有条目
• 作为后续的软件评估依据和变更的基准

8.7.2 需求文档的组织形式

文档需要有逻辑组织结构

• 例如：参照IEEE的模板

典型的组织形式包括

• 按系统能够响应的各种外部环境情况来组织
• 按系统特征来组织
• 按系统的响应方式来组织
• 按所管理的外部数据对象来组织
• 按用户类型来组织
• 按软件的工作模式来组织
• 按子系统的划分来组织

8.7.3 软件需求规格SRS的风格

描述性的自然语言文本

• 用户故事

从用例模型产生

• 用例模型与需求转化可看成可逆的过程
• 如果需求模型用例的形式表示，我们可以逆向生成需求的完整集合

从需求数据库中生成

• 商业需求数据库内置的功能来生成经过筛选的需求规格说明
• 从哪个产品线需求规格数据库中生成特定产品的需求规格说明

从混合模型中生成

• 特征模型和用例模型

8.7.4 如何选择合适的需求规格说明方式

8.7.5 用户手册作为SRS

对于用户交互的系统是比较有效的，这样系统由交互驱动
但是用户手册并没有描述

• 非功能性需求
• 不和用户交互的功能性需求（比如：函数计算、过滤器或者翻译工具的时候）
  
  

8.7.6高质量需求规格说明

• 是所有需求的集合
• 描述产品要提供的所有功能
• 是软件系统解决方案的商业合同的基础
• 是测试计划的基础
• 定义产品需求的度量标准
• 是产品需求的跟踪的先决条件
• 影响开发产品的项目计划

8.7.7 高质量需求规格说明的评价标准

• 正确性 = 经过验证的
• 无歧义
• 完整的
• 可测试 = 可以证明的
• 可修改的
• 可跟踪的
• 易理解
• 一致的
• 有序的
• 项目或产品特定的其他特征
• 简洁的

8.7.8 SRS的优缺点

优点

• 模板提高效率
• 在有模板的情况下，面对有关完整的大纲，不容易遗漏重要的信息
• List item

缺点

• 并非对于所有的系统，模板的章节设计都是类似的
• 如果仅仅为了满足标准，而填写模板的所有章节，在不相关的章节，会加入一些没有意义的内容
• 读者很难讲这些无意义的文字和真正的需求分开

8.7.9 总结

• 尽快开始写需求
• 确定哪些属性将被用于分类和细化需求
• 产生有关初始版本来刺激反馈
• 询问需求时需要遵循的法则：
• • 使用简单、直接的语言
• • 撰写可测试的需求
• • 一次只写一项需求