《软件工程》需求分析

读《构建之法》笔记
###软件需求
1.获取和引导需求
软件团队需要找到软件的利益相关者， 了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。 不同的项目需要不同的手段， 这一步骤也被叫做“需求捕捉”， 形容真正的需求稍纵即逝， 需要靠火眼金睛和敏捷的身手来发现并抓住它们。 另外， 很多时候用户并不知道自己确切的需求， 或者不愿意表达完整的需求， 软件团队需要设身处地， 替用户着想， 引导出需求。 有些需求在实现之前， 并没有用户明确表达具体的需求（例如： 没有用户说“我希望有一个偷菜的软件， 我可以偷别人家的菜”） ， 但是， 成功的团队还是可以从“用户需要和朋友之间玩游戏， 用户有证明自己能力的需求”这些角度出发， 挖掘出需求。 另外， 软件团队可以分析技术的发展趋势以及产业的变化、 社会发展的大趋势， 推测用户会产生哪些新的需求。
2. 分析和定义需求（Analysis & Specification）
这是指对从各个方面获取的需求进行规整， 定义需求的内涵， 从各个角度将需求量化（需求实现的最后期限， 实现需求大致所需的时间和资源成本， 各个不同需求的优先级， 需求带来的收益， 等等）
3. 验证需求（Validation）
软件团队要跟利益相关者沟通， 通过分析报告、 技术原型、 用户调查或演示等形式向他们验证软件团队对于这些需求的认知
4. 在软件产品的生命周期中管理需求（Management）
在软件的生命周期中， 需求在发生变化， 技术在发展， 团队成员的能力也在提高。 原来认为重要的事情可能不再重要， 有些功能原来技术上很难实现， 现在出现了捷径， 一些相关的法规会发生变化， 外部的合作伙伴突然发生变化， 这些都要求我们不断对需求进行重新审核并做出相应的调整。
#####对于软件需求的不同角度的划分
1. 对产品功能性的需求： 要求产品必须实现某些功能。 例如， 学校的选课软件只允许有学生身份的用户浏览并选择课程， 同时要求学生选择某一门课时必须要满足“先修课”的要求， 等等。
2. 对产品开发过程的需求： 要求软件的开发流程必须满足某些约束条件， 例如， 开发过程必须产生某种类型的文档， 必须在某个时间点达到某个状态， 必须对源代码施以某种约束（安全性核查、 代码版权核查、代码规范和支持文档的核查） 。
3. 非功能性需求： 这也叫“服务质量需求”（Quality of ServiceRequirement） ， 例如， 股票交易系统必须在一定时间内返回用户查询结果（它对时间的要求要比“科技文献检索”网站要高） ， 火车票购票系统、 大学选课软件必须能支持一定数量的用户同时访问， 等等。
4. 综合需求： 有些需求并不是单单一个软件模块就能满足， 例如， “购物网站必须在24小时内把货物发送到用户手中”， 这个需求牵涉到软件系统、 货物派送系统、 送货部门、 监控系统等不同部门的功能和执行能力。 软件团队和客户代表要在需求阶段把这些问题定义清楚。
###软件产品的利益相关者
很多人或机构都是某个软件的利益相关者， 软件团队在分析软件需求时要考虑如下这些利益相关者。
用户： 或称最终用户（user， end-user） ， 是直接使用软件系统的人。 取决于软件的特点， 一个软件也许有多种不同的用户。 （例如， 一个打车软件的用户有三种： 出租车司机、 顾客和监管方。 ）
顾客： 或称客户（customer， client） ， 购买这个软件或者根据合同或规定接收软件的人。 这些人不一定是软件的直接用户， 但是他们的利益和软件直接相关。 例如， 给小孩买英语学习软件的家长； 决定公司应该使用哪一款远程会议软件的主管（可能是CTO） ， 决定本公司的出租车司机应该用哪一款打车软件的管理人员； 代表委托方（甲方） 向软件团队提交需求的人员。 市场分析师： 市场部门要代表“典型用户”的需求。 监管机构： 在一些行业， 软件必须符合许多行业和政策规定（如银行、
公共交通、 通信、 矿产资源等） 。
软件工程师： 工程师也是软件需求阶段的一个重要角色， 软件的各种约束、 特性会影响到他们工作的效率、 开发难度和软件维护的难度。 他们应积极参与到软件需求阶段中来。 软件开发不可能一次满足所有利益相关者的要求， 但是我们一定要让相关角色在这个阶段有机会提出他们的需求和意见， 同时， 要弄清楚“他们想从软件中得到什么”。

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

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