《软件工程》需求分析

获取用户需求——用户调查

软件开发的过程， 就是“用户最需要的东西”在下面这一链条中传送、 转换、 实现、 扭曲或丢失的过程。 用户最需要的>用户表达出来的>软件团队能理解的 + 团队的商业目标>软件团队成员具体表达出来的（PM写Spec） >在各种约束条件下， 具体执行表达出来的（Dev写代码） >验证通过的（Test） >通过各种渠道告诉目标用户（发布/推广） >用户终于能用上了， 但是他们不满意
几种常用的用户调研方法
1. 焦点小组（Focus Group）
找到一群目标用户的代表， 加上项目的利益相关者来讨论用户想要什么， 用户对软件的评价等等。
2. 深入面谈（In-depth Interview）
通过详细的面谈， 广泛而深入地了解用户的背景、 心理、 需求等。 这通常是一对一的采访。 这种方法费时费力， 效果往往取决于主持面谈的团队成员的能力。 深入面谈这一方法也可以用在某一特定领域， 例如软件的用户可用性和用户界面， 这也可以称为软件可用性研究（Usability Study）
3. 卡片分类（Card Sorting）
通常， 团队收集到的需求都是杂乱无章的， 不同的角色从不同角度表达了希望软件能做什么， 有什么特点， 能解决自己的什么痛苦， 或者有什么好玩的地方， 等等。 在收集这类反馈时我们可以利用“卡片分类”的办法， 把各种需求做成便于规整的小卡片（也可以写在小贴纸上） ， 然后反复进行下列活动： 讨论 → 明晰定义 → 归类 → 排序这一方法可以帮助我们更好地统一大家对软件需求的认识， 量化各种特性， 更好地定义一个软件的信息架构、 用户的工作流程、 软件菜单结构、 站的浏览路径、 各种内容的层次关系等。
4. 用户调查问卷（User Survey）
这种方法是指向用户提供事先规定好的问题， 让用户回答。 我们在大街上碰到过不少。 有时候用户在浏览某个 站时， 一个弹窗会跳出来， 打断用户的思路， 不客气地要求用户回答几个问题。 用户在回答这类问题时， 是否会心不在焉， 乱点一气br> 5. 用户日志研究（User Diary Study）
这一调研方式要求用户记录自己日常工作或生活中与所用软件相关的行为， 供软件团队分析。 用户可以写类似日记体的文字描述， 也可以每天填表（例如跟踪自己每天的饮食种类） ， 也可以使用软件来跟踪。 这是用户调查在时间上的延长， 要求用户有很高的自律能力。 另外， 如何保护用户的隐私也是一个问题。
6. 人类学调查（Ethnographic Study）
这种方法听起来学术味很浓， 其实可以解释为—和目标用户“同劳动”。 例如， 与其坐在办公室里想象如何给老年人设计手机， 去和老年人生活几天， 从生活中得到体会和需求。 请看一个采用此类法的。 人类学的用户调查听起来很高深， 其实未必—也许一直生活在目标人群中， 只不过你对这些需求不够敏感罢了。
7. 眼动跟踪研究（Eye Tracking）
软件团队发布了内容丰富的互联 应用， 或者大幅度更新了 站的用户界面， 但是很多用户反映软件更难用了， 怎么办大部分的软件都向用户展现了很多信息， 也有很多交互， 怎样才能让用户容易找到设计人员想让他们看到的信息， 找到自己想用的功能用户浏览 页上的众多内容通常是什么样的规律一些研究发现了F模式。
用户通常浏览通栏标题， 然后目光沿着左侧下行， 再平行浏览下面的子标题。 如果你有重要内容希望用户知道， 应该放在什么地方呢br> 8. 快速原型调研（Quick Prototype）
等软件做好了再去找用户做调查， 未免太费时， 并且修改的成本很高。能否快速地取得用户的反馈这时不妨拿一些纸张模型， 让用户去使用， 得到反馈。 这也是用户参与式设计的一个例子。
9. A/B测试（A/B Testing）
如果你的产品已经有一些用户在用， 你想对用户界面做一些改进， 但是又不知道到底有多少用户会喜欢新的界面， 怎么办例如， 你的 站是两栏的布局， 但又很想试一下三栏的布局方式，例如， 你想用弹窗来促使用户对某个重要信息作出反应， 是把弹窗放在右下角呢， 还是放在屏幕中央这时候， 你是找新的用户去做一对一的深入调研， 还是跑到大街上去发调查问卷为什么不能让你现有的用户告诉你哪一种设计比较好呢这时候不妨考虑A/B测试。
A/B测试看起来很简单：
决定试验哪两种不同的UI， 以及衡量标准、 数据收集流程、 试验运行时间、 人数；
在技术上实现A/B测试（通常在5%—10%的用户上运行试验） ；
收集数据， 分析数据， 形成结论。