2、分析和定义需求（Analysis&Specification）
也就是需求的规整和量化，指定最后期限、优先级等
3、验证需求（Validation）
4、在软件产品的生命周期中管理需求（Management）
对软件的需求，也可以从不同角度做下面的划分：
1、对产品功能性的需求：必须实现的功能
3、非功能性需求：也称服务质量需求，比如要求高速度、高并发
4、综合需求：多模块多部门共同完成的需求
一般包括以下几种：
1、用户：使用软件的人
2、客户：购买软件的人，不一定是直接用户
3、市场分析者：代表典型用户的需求，可能是市场部门的成员，或独立的市场分析人士
4、监管机构：软件需要复合行业和政策规定
5、系统/应用集成商：负责给客户提供咨询、服务、集成等工作，也可能会把客户的需求分解，交付给下一级的服务团队来完成
6、软件团队
7、软件工程师
很多时候软件开发工程师和用户相隔很多环节，如：
用户-客户-系统集成商-应用集成商-二级应用集成商-软件团队-工程师
用户调研有以下几种形式：
1、焦点小组（FocusGroup）
2、深入面谈（In-depthInterview）
这通常是一对一的采访，效果取决于主持面谈的团队成员的能力，软件项目成员可以在一旁观察用户如何使用软件，也可以隐蔽在单向玻璃后，或通过录像观察。用户使用的软件不一定是自己公司开发的软件，也可以使用别的软件，找出此类软件的问题。
3、卡片分类（CardSorting）
团队收集到的需求常常是杂乱无章的，此时我们可以把各种需求做成小卡片，然后通过讨论、定义、归类、排序来整理软件需求
4、用户调查问卷（UserSurvey）
设计调查问卷时有一些常见的错误：
（1）问题定义不准确
（2）使用含糊不清的词语
（4）问题带有引导性的倾向
（5）问题涉及用户隐私、用户所在公司商业机密等
用户调查问卷的问题可以有如下方式：
（1）全开放式问题，也就是问答题
（2）二项选择题，回答是或否，但是了解情况不够深入
（3）多项选择
（4）顺位选择题，也就是有优先级的多选
5、用户日志研究（UserDiaryStudy）
6、人类学调查（EthnographicStudy）
7、眼动跟踪研究（EyeTracking）
一般用来弄清楚用户浏览内容的规律
8、快速原型调研（QuickPrototype）
软件还未做好时，用一个纸张模型或木块模型让用户去使用和反馈
9、A/B测试
这种测试就是同时在技术上实现两套方案，然后收集数据来观察大家的喜好。这种方式运行成本较大、数据可能不会真实反应用户的情绪、难以摸清数据和用户心理的关系、用户可能反感
下图在四个维度区分了这些方式：
讨论关于产品需求的创新想法时，经常需要多方面考虑问题，得到他人的信服，此时通过NABCD模型来分析是一个有效的方法。
1、N代表need，需求
主要回答产品解决了用户的什么需求，形式并不重要，解决痛点的方案才是关键
2、A代表approach，做法
也就是完成需求的具体做法
3、B代表Benefit，好处
能给用户带来什么好处？尤其是在用户已经有了其他解决方案的前提下
4、C代表competitors，竞争
产品市场有多大？有多少竞争者？先进入市场的产品有先发优势（FirstMoverAdvantage），后进入市场的产品有种种不利的因素，当然也有后发优势（SecondMoverAdvantage），可以用一张图来表达产品需求情况：
这张图可以清晰的表达我方优势在哪里，我方劣势在哪里。
5、D代表delivery，推广
有了NABCD模型，团队成员就可以用简明的语言把自己项目的特点说出来，这种简明的表达方式又叫电梯演说：
根据实际需求的特点，我们可以把功能分为
1、杀手功能（Core）/外围功能（Context），杀手功能就是产品的某个功能比其他产品好一个数量级，外围功能就是相对杀手功能的其他功能
2、必要需求（MissionCritical）/辅助需求（Enabling），必要需求就是缺少之后导致用户无法正常使用的需求，相对的就是辅助需求
这四个划分结合起来就组成了功能分析的四个象限：
对于不同的功能我们有以下几种策略：
1、维持：以最低成本维持此功能
2、抵消：快速的达到足够好，和竞争对手差不多
3、优化：花大力气做到行业最好
4、差异化：产生同类产品比不了的功能和优势
5、不做
对功能的位置不同，我们的策略也不同：
产品的各类功能和用户的满意度的关系也不一样，对于核心功能（如查询速度）来说，功能质量和用户满意度呈线性关系；对于基本功能（如稳定性）来说，投资超过一定程度用户满意度就不会上升了；对于让用户惊喜的功能，这些功能一旦出现就会给用户满意度带来增加，而且随着质量提高用户会非常满意这个产品。综上所述，各种投资的不同效果如下：
在开始估计之前，我们应该先分清楚几个概念：目标、估计和决心。目标是未必能实现的，估计是基于目前了解的情况规划的，决心是一个可能不会完成的保证。
合理估计的关键在于找出估计后面隐藏的种种假设，快速沟通达到意见一致的方法是找到一个主持人，然后主持几轮讨论，先确定大家对目标有统一的理解，然后每一轮统计估计结果，然后询问估计背后的前提假设，找到合理的假设，然后继续循环讨论。
提高估计能力的方法有参考前人的经验、快速原型法（找一两个人去探路）。
由上述公式可得，项目的复杂程度由需求的复杂程度和技术的复杂程度决定，下面的二维图表述了这些关系：
软件成本分析的经典模型CO-COMO全面描述了影响软件成本的各种因素：
在敏捷的开发流程中，团队一般不过分强调估计的价值，如果猜错了就调整项目进度，不要为了猜不准而停滞不前。快速交换意见得到粗粒度的估计，然后就进入实现阶段，经过一次里程碑后，再去回头看看估计和实际的差距，经过一两个里程碑，就可以估计的比较准确了。
WBS（workbreakdownstructure）分而治之是将大任务逐步分解成一个个小的具体的交付件。WBS分割的结果是一棵树，所有子节点都最终有一个根节点。每个节点展示的是结果，而不是过程。
WBS的一个例子：
如果文档是交付给客户，或者开发团队要付出很多人力来制作，就可以算在WBS中。