1. 需求分析介绍

搞清楚了 “要解决什么问题”！

1.1 需求分析主要涵盖哪些问题

为什么要设计该系统br> 系统由谁使用br> 系统要做什么br> 系统涉及哪些信息br> 对解决方案有何额外限制br> 如何使用该系统br> 质量需达到何种程度/p>

1.2 需求分析分类

2.2.2 通过业务过程（建模和分析的方法）

对现有业务过程的分析有助于识别业务问题并加以改进：

• 找出并列举当前业务过程中的问题
• 分析问题的本质（遗漏好用需求
• 分析改进的机会
• 分析改进的实质（自动化程改进

2.2.3 通过组织规章制度（文本阅读、文档处理等）

组织规章制度为我们提供了一个客观的、可参依据

• 规章制度定义当前最佳实践
• 分析规章制度有益于确定业务规则和约束条件
  1）业务规则：描述对业务过程的要求，如系统支撑的业务过程的结构、控制、行为效果
  2）约束：对系统开发过程的管理限制，主要涉及经济、政治、技术和环境四个方面，具体包括项目资源、时间、目标环境涉及系统本身
• 组织规章中往往还涉及过程自动化、工作流、关系、交互等内容

2.2.4 通过现有系统

用户手册、数据样本、界面描述、 告样本、截屏截图

2.2 获取需求的方法

常见的需求获取方法包括用户访谈、问卷调查、釆样、情节串联板、联合需求计划、文档分析、头脑风暴、原型化方法、建模方法、需求讨论会等。

2.2.1 访谈

人少但懂得多，最好有专家在。

1）技巧

• 访谈开始
  谈一些比较轻松，不太敏感的话题
  如天气，体育比赛，就受访者的照片，办公桌陈设发表感叹
• 询问受访者是否同意录音
  将录音笔放在受访者面前，提醒他们可在任何时候关闭
• 先问比较容易回答的问题
  如个人信息，在这里工作多久等问题
• 根据对方提出的某些现所继续体温
  关注用户说的能暗示你的方案可能错误的时候，“您可以就此多谈谈吗
• 将自由发挥性质的问题放在最后
  “您还有什么想补充的吗

2）访谈过程

• 明确访谈的目的
  通过访谈获得什么信息么时候目的达到了/p>

• 设计访谈提纲

• 界定目标人群

• 邀请访谈用户

• 进行用户访谈
  轻松开场、挖掘、把控

• 整理访谈数据
  反馈讨论、管理输出

3）访谈注意事项
避免一组固定的问题；
优先关注用户行为背后的原因；
避免让用户成为设计师；
避免讨论技术细节；
避免诱导性问题；
鼓励讲故事；
避免问无法回答的问题，比如如何系鞋带；
避免问基于隐含知识的问题，以及脱离了环境和上下文的问题；
注意面谈者的态度也可能产生有偏见的回答。

2.2.2 问卷调查

不同时间、不同地点、多人参与、分析师观察、验证有限次面谈得出的结论、针对特定问题

• 预先定义问题
• 面对广泛涉众的时候使用
• 统计分析的结果看起来更科学

1）优点
可快速获得大量反馈
可远程执行
可搜索关于态度、信念及特性的信息
2）缺点
简单的分类导致对上下文的考虑较少
留给用户自由表达其需要的空间较小
3）注意事项
选择样本时可能存在偏见
自愿的问卷回答者可能存在偏见
样本规模太小
自由发挥问题难于分析
对答案有诱导性的提问
问题的妥当性
含糊的问题

2.2.3 群体诱导

在一个房间中聚集3~20个干系人
每个人都将自己的观点大声说出来
群体的答案往往比个体好

1）什么时候采用群体诱导技术br> 当很多人各自知道关于整体的一小部分时
当人们需要彼此交互来得到一个最优的答案时
当你能把人们聚集在一起时
需要匿名用一些工具
在不同的地方用一些工具

2）群体诱导技术

2.2.14 A/B 测试

产品已经有用户在用，相对用户界面做些改进，但又不知道用户是否会欢迎时，可以配置A/B 测试使用环境。

• 确定待试验的两种UI
• 确定衡量标准
• 确定数据搜索流程
• 确定试验运行时间
• 确定人数（5~10%的用户）
• A/B 测试的技术实现
• 搜集数据
• 分析数据
• 作出结论

2.2.15 用户行为数据在线采集

在线对用户的访问数据进行分析和统计，得到对新产品设计的启示。

• 用户操作数据采集
  交互过程数据、眼动数据、页面访问时间、访问内容数据、用户偏好数据等
• 操作数据统计
  厂商、版本、IP地址、日访问量、地域信息、访问频次、用户身份、访问时长、打分等

2.3 获取技术的选择

• 获取界面需求
  原型法、情景法与建模法比较有效

• 获取业务逻辑需求
  观察法、亲身实践、面谈和情景法有利于对业务逻辑的精确理解和描述

• 对未来系统的信息和数据结构进行获取
  面谈和现有系统分析是最为有效的

要建立完整精确的模型很困难，建立完整的原型也不现实，因此，要根据需要和客观条件灵活运用。

2.4 获取需求注意事项

2.4.1 用户需求获取是一门倾听的艺术

• 倾听干系人的艺术
• 引导干系人的艺术，使得干系人的回答给出有价值的信息
• 协助和鼓励干系人表述他们需求的艺术

2.4.2 什么是“足够好”的需求管理

• 什么是“足够好”的人寿保险br> 1）足够多，所以你晚上可以睡得很安心，即使你不在了你关心的人也能得到很好的照顾
  2）但还没有太多，以致你因为担心保险支付的问题而无法入睡
• 什么是“足够好”的需求管理br> 1）足够 ，所以你能让客户满意
  2）但还没有超过一定限度，以致项目延期或超支

2.4.3 比谁更聪明/h3>

• 不要尝试向干系人证明你是聪明的
• 抓住所有的机会表现你认为干系人是聪明的
• 对比这两种情况
  客户问题：我的电梯太慢了
  回答1：好的，告诉我为什么你觉得电梯慢
  回答2：我不这么认为，我觉得你的电梯有吞吐量问题，不是速度问题

2.4.4 维护术语表

• 经验表明很大一部分需求沟通错误是由术语表达存在歧义造成的
• 确定术语表
  1）问这样的问题“X的含义是
  2）记录所有取得共识的术语定义

2.4.5 采用合适的需求获取技术

• 只采用一种获取技术是不够的
• 获取技术的选择与项目参与人相关
• 与待理解的需求相关
• 与具体应用领域相关

2.5 各方法使用情况

3.2.2 流程图模型

3.2.2.1 数据流程图-功能模型（功能如何改变数据的）

从数据传递和加工的角度，利用图形符 通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能；

复杂的数据流程图，要分层去画，思路更清晰，更容易理解和阅读！！！

2. 业务流程 + 泳道图（角色或状态）

业务流程图结合泳道图，可以将角色和业务流程相结合，流程更清晰易懂。

3.2.3 类模型

类的划分，哪些属性和哪些方法绑定到同一个类，根据数据流图等进行分析。
同一类型放到一个包里面

3.2.4.2 序列图

3.2.6 判定树和判定表

4. 撰写软件需求规格说明书（SRS）

4.1 简介

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

4.2 文档的组织形式

• 文档需要有逻辑组织结构
  如：参照IEEE 的模板

• 文档的主要内容
  （1）范围
  （2）引用文件
  （3）需求
  （4）合格性规定
  （5）需求可追踪性
  （6）尚未解决的问题
  （7）注释
  （8）附录

4.3 软件需求规格说明书风格

• 描述性的自然语言文本
  用户故事
• 从用例模型产生
  • 用例模型与需求转化可看成可逆的过程
  • 如果需求模型以用例的形式表示，我们可以逆向生成需求的完整集合
• 从需求数据库中生成
  • 商业需求数据库有内置的功能来生成经过筛选的需求规格说明
  • 从产品线需求规格数据库中生成特定产品的需求规格说明书
• 从混合模型中生成
  特征模型和用例模型

4.4 选择何使的需求规格说明方式

考虑以下两个具体项目场景：
1）小项目，1名程序员，2个月的开发周期
程序员直接和用户对话，写了两页纸的备忘录
2）大型项目，50名程序员，2年的开发周期
专门的团队进行需求建模与分析，撰写了500页的需求规格说明

4.6 用户手册作为SRS

• 撰写用户手册作为一种性价比高的一箭双雕的方法，同时获得SRS和用户手册

• 用户手册作为SRS对于和用户交互的系统是比较有效的，这样系统由交互驱动

• 好的手册描述了所有用例的所有场景

  • Fre Brooks 的《人月神话》中描述了将用户手册作为需求规格说明书的做法
  • 据说在苹果的第一台电脑编码工作开始之前用户手册就写好了

• 但是，用户手册并没有描述

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

用户手册大纲

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

4.7 需求规格说明的用户

4.8.3 保证需求规约是简洁的

• 定义：一个需求描述是简洁的
  • 一个需求只描述了系统的一个独立特征
  • 除了必须的信息外没有包含其他信息
  • 用清晰、简单、可理解的词表述
  • 避免“应该”、“可以”、“可能”之类的用词
• 举例：
  • “急救电话的响应应本着先到先响应的原则” 简洁
  • “急救电话应该按照其拨入的次序存入一个先入先出的等待队列当中，并且按照进入队列的次序逐一应答” 复杂

4.9 需求规格说明生成过程

使用需求数据库时，优先通过数据库，从新生成需求规格说明

• 创建任何类型的需求规格说明最优先的方式是通过需求数据库生成它

4.11 需求规格说明SRS 模板

4.11.1 简介

• SRS 需要根据预先定义的标准章节模式来组织，即根据模板来撰写
• SRS 的模板使得撰写统一的SRS 变得简单
• 对于QA 人员来说定义SRS 指标变得简单
• 模板也适用于业务需求和系统需求
• 模板可以被用于半自动地从需求数据库或者用例模型生成SRS

4.11.2 举例（IEEE）

从整体上描述系统的外部接口，相关的用户，软硬件平台以及操作和节点上的一些要求
对系统的功能性和非功能性需求给出详细的描述


4.11.3 SRS 模板的优缺点

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

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

4.12 需求撰写目标

• 首先在干系人之间沟通需求
• 其次建立合同约定，为后续的验证提供基准，为后面的需求变更提供参考
• 系统的规约可以给技术和非技术用户来使用，所以应该尽快的开始撰写需求，产生一个初始的版本来获取用户反馈，确定哪些属于可以用于进一步细化分类需求，将其定义到需求的列表当中
• 在遇到问题时，直接询问用户往往比咨询场外的专家更为有用

4.13 总结

• 尽快开始写需求
• 确定哪些属性将被用于分类和细化需求
• 产生一个初始版本来刺激反馈
• 询问用户往往比咨询专家更有用
• 撰写需求时需要遵循的法则：
  • 使用简单、直接的语言
  • 撰写可测试的需求
  • 使用定义好的并达成共识的术语
  • 一次只写一项需求，保持需求项之间的独立性

随时准备迎接需求变化

获取到原始需求之后，我们应该本着随时准备迎接需求变化的心态

• 这是一种态度
• 越多的干系人参与，将获得越多的需求特征
• 但不能通过减少干系人的方法来解决这个问题
• 干系人有改变他们想法的权利
• 不要问：“这是你最终的需求吗
• 请将变化看成机会，而不是威胁

注意：
统一名词
任何缩写第一次出现时，必须用全称，之后给出缩写称呼

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！