第八章 需求获取

课程来源： 学堂在线 -- 清华大学 -- 软件工程

重点掌握概念和知识点：

• 需求工程师的职责
• 软件需求的定义
• 获取软件需求的主要途径
• 软件需求文档的框架

8.1 需求工程师

需求工程成为软件工程和系统工程的重要分支领域之一。

需求阶段主要关注：软件和系统需求的获取、建模、分析、验证和管理

学习目标

• 产生软件产品的新的创意
• 与干系人进行有效的沟通
• 基于目标、场景和主体建模软件系统的需求
• 利用图形化的方法对软件系统的行为与结构进行分析

注意点

1. 区分问题的分析与解决方案的生成
2. 根据软件项目本身的规模、人员的技能、客观的条件、项目的成本选择合适的需求获取技术、建模方法以及合理的软件系统设计方案

当代需求工程师

1. 分析问题和解决问题的能力  --识别错误假设，确保一致性
2. 人际沟通及交流能力 --减少彼此误解，提升客户满意度
3. 软件工程知识及技能  --提升依从性
4. 应用领域有关知识  --提高支持速度和效率
5. 书面语言组织和表达能力  --撰写优质需求文档
6. ...

8.2 需求定义

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

“需求管理”三项任务

1. 学习       --需求获取
2. 剪枝       --需求优选
3. 文档化   --撰写需求规格说明书

需求将作为系统开发，测试，验收，提交的正式文档依据 。

需求的内容

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

涵盖如下内容

为什么要设计该系统

系统由谁使用

系统要做什么

系统涉及哪些信息

对解决方案有何额外限制

如何使用该系统

质量需达到何种程度

问题与解决方案分开

建立单独的问题描述文档：

• 表面上的问题vs. 实际要解决的问题
• 问题描述提交给干系人进行讨论
• 按问题描述选择候选设计方案
• 问题描述作为测试用例的来源

什么是需求

领域性质 ：无论无论系统存在与否均存在的应用领域的性质

需求：由系统的存在而使能的应用领域性质

规约描述：描述系统为满足需求而应具有的行为

需求证明的标准：

1. 运行在某台机器上的程序满足规约描述
2. 针对给定的领域性质，规约描述满足需求

需求验证的标准(完备性)：

1. 是否已发现所有重要需求
2. 是否已发现所有有关的领域性质 

 8.6 需求获取技术

面谈

• 可以见到干系人
• 很少的人了解很多内容
• 真正的专家存在的时候
• 干系人不能被聚到一起的时候
• 问题不依赖交互来得到最后解答时

类型：

• 有组织的面谈通常事先制定议程，问题可以是开放的
• 自由面谈则无既定议程

优点：可以获取大量丰富的数据、有助于发现观点、感受、目标及事实 、可以进行深入讨论

缺点：难以对问题的回答者进行比较、大量数据定性，难以分析

技巧

面谈开始时，谈一些比较轻松，不太敏感的话题

• 天气，体育比赛、就受访者的照片、办公桌陈设发表感叹

询问受访者是否同意录音

• 将录音笔放在受访者面前，提醒他们可在任何时候关掉

先问比较容易回答的问题

• 如个人信息： “您在这儿工作多久了?”

 根据对方提出的某些线索继续提问

• 关注用户说的能暗示你的方案可能错误的时候 • “您可以就此多谈谈吗?”

将自由发挥性质的问题放在最后

• “您还有什么想补充的吗?”

问卷调查

• 预先定义的问题
• 面对广泛涉众的时候使用
• 统计分析的结果看起来更为科学
• 什么时候使用问卷调查
  • 大基数的被访者
  • 需要关于良好定义的特定问题的答案
  • 验证有限次面谈得出的结论
  • 当你需要一个特定的结果的时候

优点：快速获得大量反馈、远程执行、可搜集关于态度、信念及特性的信息

缺点：上下文考虑较少、留给用户自由表达其需要的空间较小

群体诱导技术

• 在同一个房间中聚集3-20个干系人
• 每个人都将自己的观点大声说出来
• 群体的答案往往比个体好
• 什么时候采用群体诱导技术
  • 当很多人各自知道关于整体的一小部分
  • 人们需要彼此交互来得到一个最优的答案
  • 当你能把人们聚在一起

参与调查法

• 类型
  • 专题小组会议
  • 头脑风暴

优点：交互更为自然、可以抛砖引玉 （运用实体模型、情节串联板）

缺点：分组未必自然、少数服从多数带来的危险、对技术问题仅给出表面化的回答、需要训练有素的协调人

注意事项

• 样本偏见
• 统治与屈从

亲生实践

优点：总是上下文相关的、能够发现其它方法无法发现的细节

缺点：时间成本和开销很大、获取过于丰富的细节，难于分析、无法就改进建议所带来的结果给出更多评论

注意事项：

• 有被同化的危险

8.7 撰写需求文档

软件需求规格说明书

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

需求文档的组织形式(IEEE)

•  按系统能够响应的各种外部环境情况来组织 --实际使用场景下的条件

• 按系统特征来组织

• 按系统的响应方式来组织

• 按所管理的外部数据对象来组织

• 按用户类型来组织

• 按软件的工作模式来组织

•  按子系统的划分来组织 --命令控制子系统、数据处理子系统...

按照其本身的需要，合理的、有逻辑的方式来组织。

软件需求规格说明的风格

• 描述性的自然语言文本
• 从用例模型产生
• 从需求数据库中产生
• 从混合模型中生成

生成不同风格的SRS 总览

撰写用户手册是一种性价比较高的策略，通过撰写用户手册，同时获得了软件的需求说明书。对于和用户交互的产品来说是非常有效的，但是用户手册会忽略非功能性需求以及不和用户交互的功能性需求(函数计算、过滤器或者翻译工具等等)。

常见用户手册大纲

• 介绍
  • 产品总览及基本原理
  • 术语和基本特征
  • 展示格式与报表格式的总结
  • 手册的大纲
• 开始
  • 开始指令
  • 帮助模式
  • 样例运行 
• 操作模式
  • 命令行/对话框/报告 
• 高级特性
• 命令语法和系统选项 

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

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

简洁的

定义：一个需求描述是简洁的

• 描述了系统的一个独立特征
• 除了必须的信息之外没有别的多余信息
• 用清晰、简单、可理解的词表述
• 避免“应该”、“可能”、“可能” 之类的用词

IEEE-830 SRS模板大纲

最为重要的是对系统需求的详细描述部分，如下

 

SRS模板的优缺点

优点 

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

缺点

• 模板设计不适用所有系统
• 为了满足标准，在填写时加入无意义的内容
• 读者难以将无意义的内容与真正需求区分