需求分析
需求的步骤和需求分类
找到软件需求的几个步骤：
1、获取和引导需求（Elicitation）
这一步骤也被称为需求捕捉，一方面很多时候用户描述不清或不愿意表达完整需求，一方面这些需求来源可能并不同，也许来自外界，也许来自软件企业本身，甚至来自技术团队本身，如技术性的需求，更好的了解用户行为而加上的收集信息需求（也被称为遥测技术Telemetry）
2、分析和定义需求（Analysis & Specification）
也就是需求的规整和量化，指定最后期限、优先级等
3、验证需求（Validation）
向利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证这些需求的认知
4、在软件产品的生命周期中管理需求（Management）
面对一些变化我们要做出相应的调整，如需求变化、功能很难实现、有些功能不再重要、出现了一些捷径、相关法规的变化、外部合作伙伴的变化等。
对软件的需求，也可以从不同角度做下面的划分：
1、对产品功能性的需求：必须实现的功能
2、对产品开发过程的需求：开发过程必须满足某些约束条件，如产生某种文档、某个时间点达到某种状态、安全性核查等
3、非功能性需求：也称服务质量需求，比如要求高速度、高并发
4、综合需求：多模块多部门共同完成的需求
软件产品的利益相关者
一般包括以下几种：
1、用户：使用软件的人
2、客户：购买软件的人，不一定是直接用户
3、市场分析者：代表典型用户的需求，可能是市场部门的成员，或独立的市场分析人士
4、监管机构：软件需要复合行业和政策规定
5、系统/应用集成商：负责给客户提供咨询、服务、集成等工作，也可能会把客户的需求分解，交付给下一级的服务团队来完成
6、软件团队
7、软件工程师
很多时候软件开发工程师和用户相隔很多环节，如：
用户-客户-系统集成商-应用集成商-二级应用集成商-软件团队-工程师
获取用户需求——用户调研
用户调研有以下几种形式：
1、焦点小组（Focus Group）
找到一群目标用户的代表，加上其他利益相关者，大家一起讨论用户想要什么。缺点是很多人的情况下发表的意见不真实、可能出现表达能力强的人控制局面、讨论者对新事物不能提供有价值的想法、往往选择那些最符合自己利益的意见。这种形式也叫做推进会议（Facilitated Meetings）
2、深入面谈（In-depth Interview）
这通常是一对一的采访，效果取决于主持面谈的团队成员的能力，软件项目成员可以在一旁观察用户如何使用软件，也可以隐蔽在单向玻璃后，或通过录像观察。用户使用的软件不一定是自己公司开发的软件，也可以使用别的软件，找出此类软件的问题。
3、卡片分类（Card Sorting）
团队收集到的需求常常是杂乱无章的，此时我们可以把各种需求做成小卡片，然后通过讨论、定义、归类、排序来整理软件需求
4、用户调查问卷（User Survey）
设计调查问卷时有一些常见的错误：
（1）问题定义不准确
（2）使用含糊不清的词语
（3）提出一个让用户花很多时间才能回答上来的问题
（4）问题带有引导性的倾向
（5）问题涉及用户隐私、用户所在公司商业机密等
用户调查问卷的问题可以有如下方式：
（1）全开放式问题，也就是问答题
（2）二项选择题，回答是或否，但是了解情况不够深入
（3）多项选择
（4）顺位选择题，也就是有优先级的多选
5、用户日志研究（User Diary Study）
这一调研方式要求用户记录自己日常工作或生活中使用软件相关的行为，可以用文字描述或每天填表，也可以使用软件来跟踪，注意要保护用户的隐私
6、人类学调查（Ethnographic Study）
假装自己是目标用户，以目标用户的心理使用软件，或者长时间观察目标用户的使用情况和心理
7、眼动跟踪研究（Eye Tracking）
一般用来弄清楚用户浏览内容的规律
8、快速原型调研（Quick Prototype）
软件还未做好时，用一个纸张模型或木块模型让用户去使用和反馈
9、A/B测试
这种测试就是同时在技术上实现两套方案，然后收集数据来观察大家的喜好。这种方式运行成本较大、数据可能不会真实反应用户的情绪、难以摸清数据和用户心理的关系、用户可能反感
下图在四个维度区分了这些方式：
竞争性需求分析框架
讨论关于产品需求的创新想法时，经常需要多方面考虑问题，得到他人的信服，此时通过NABCD模型来分析是一个有效的方法。
1、N代表need，需求
主要回答产品解决了用户的什么需求，形式并不重要，解决痛点的方案才是关键
2、A代表approach，做法
也就是完成需求的具体做法
3、B代表Benefit，好处
能给用户带来什么好处？尤其是在用户已经有了其他解决方案的前提下
4、C代表competitors，竞争
产品市场有多大？有多少竞争者？先进入市场的产品有先发优势（First Mover Advantage），后进入市场的产品有种种不利的因素，当然也有后发优势（Second Mover Advantage），可以用一张图来表达产品需求情况：
这张图可以清晰的表达我方优势在哪里，我方劣势在哪里。
5、D代表delivery，推广
怎样把创新产品交到用户手中？是放到导航页面还是放在手机应用商店？需要做广告和公关活动吗？
有了NABCD模型，团队成员就可以用简明的语言把自己项目的特点说出来，这种简明的表达方式又叫电梯演说：
功能的定位和优先级
根据实际需求的特点，我们可以把功能分为
1、杀手功能（Core）/外围功能（Context），杀手功能就是产品的某个功能比其他产品好一个数量级，外围功能就是相对杀手功能的其他功能
2、必要需求（Mission Critical）/辅助需求（Enabling），必要需求就是缺少之后导致用户无法正常使用的需求，相对的就是辅助需求
这四个划分结合起来就组成了功能分析的四个象限：
对于不同的功能我们有以下几种策略：
1、维持：以最低成本维持此功能
2、抵消：快速的达到足够好，和竞争对手差不多
3、优化：花大力气做到行业最好
4、差异化：产生同类产品比不了的功能和优势
5、不做
对功能的位置不同，我们的策略也不同：
产品的各类功能和用户的满意度的关系也不一样，对于核心功能（如查询速度）来说，功能质量和用户满意度呈线性关系；对于基本功能（如稳定性）来说，投资超过一定程度用户满意度就不会上升了；对于让用户惊喜的功能，这些功能一旦出现就会给用户满意度带来增加，而且随着质量提高用户会非常满意这个产品。综上所述，各种投资的不同效果如下：
随着时间的推移，这些功能的属性也会发生变化，如核心功能演变成基本功能、惊喜功能变成核心功能等。
计划和估计
在开始估计之前，我们应该先分清楚几个概念：目标、估计和决心。目标是未必能实现的，估计是基于目前了解的情况规划的，决心是一个可能不会完成的保证。
合理估计的关键在于找出估计后面隐藏的种种假设，快速沟通达到意见一致的方法是找到一个主持人，然后主持几轮讨论，先确定大家对目标有统一的理解，然后每一轮统计估计结果，然后询问估计背后的前提假设，找到合理的假设，然后继续循环讨论。
提高估计能力的方法有参考前人的经验、快速原型法（找一两个人去探路）。
长期的实践过程中，软件工程师发现实际时间花费Y主要取决于两个因素，对某件事的估计时间X，以及他做过类似开发工作的次数N：Y=X±X/N，当一个人没有做过类似的开发工作时，实际花费时间会无穷大。当一个人做过一次类似开发工作时，实际花费时间范围是0到2X，如果员工一直在做类似的项目，那么变化的范围会越来越小，准确度也越来越高。
由上述公式可得，项目的复杂程度由需求的复杂程度和技术的复杂程度决定，下面的二维图表述了这些关系：
软件成本分析的经典模型CO-COMO全面描述了影响软件成本的各种因素：
上面的每一项都量化成一个因子，如果是完全在掌控中该因子就是1，如果完全不知道该因子就是10，软件项目所需时间Y会落在下面的范围中：
其中Y0是估计项目时间，F0到Fn是上文提到的各种因子。
在敏捷的开发流程中，团队一般不过分强调估计的价值，如果猜错了就调整项目进度，不要为了猜不准而停滞不前。快速交换意见得到粗粒度的估计，然后就进入实现阶段，经过一次里程碑后，再去回头看看估计和实际的差距，经过一两个里程碑，就可以估计的比较准确了。
分而治之WBS
WBS（work breakdown structure）分而治之是将大任务逐步分解成一个个小的具体的交付件。WBS分割的结果是一棵树，所有子节点都最终有一个根节点。每个节点展示的是结果，而不是过程。
WBS的一个例子：
如果文档是交付给客户，或者开发团队要付出很多人力来制作，就可以算在WBS中。
WBS描述了要交付的东西，这主要是给产品的接受方或利益相关者看的，具体为了完成结果所做的工作可以用开发团队比较熟悉的项目管理工具来描述任务。
有一些需要考虑、分析和探索的问题，花在这些问题上的时间都可称为技术研讨，短期的技术研讨应该在功能的设计阶段完成，不需要单独的交付成果。没有具体结果或报告的技术研讨，对公司基本是没有贡献的。