区分业务需求、用户需求和软件需求

从业这么多年，大大小小的项目也做了不少，有多少是真正成功的？当然，如何定义“成功”各有各的标准，从交付的角度来看，项目都是成功的。因为不管过程如何曲折，时间、成本如何超支，最终无法验收、收不到钱的项目实在少之又少。但这样的标准，对项目过程的改进毫无借鉴作用。 Standish Group是一家专注于软件项目绩效的咨询机构，它定义了用于衡量项目“成功”的5个指标：OnTime, OnBudget, OnGoal, Value, Satisfaction。按照这样的定义，我恐怕找不出一个成功的项目了。事实上，全球真正成功的项目也就30%左右，一半多的项目都处在“挣扎”状态。详见下图：

当谈论起项目失败的原因时，大部分人都会“归功”于需求。“客户自己都不知道要做什么”，“功能刚做完，需求又变了”，“客户怎么不上天啊”，这些话我们都耳熟能详了。的确，需求是整个项目的基石，需求的质量直接影响着整个项目的进展。 1994年Standish Group发布了软件项目的CHOAS报告，在影响项目成功的十大要素中，需求相关的要素占比37%左右，具体是：用户的参与，清晰的需求描述，现实的客户期望。有趣的是在2015年的报告中，需求相关的要素只剩下用户参与这一条，占比15%。这说明需求分析的专业性20年来有了很大的提高，用户也逐渐回归理性。 94版的报告同时列出了导致项目失败的10大因素，跟需求相关的占了51.6%，分别是：不完整的需求，缺乏用户参与，不切实际的用户期望，需求变更频繁，提供了不再需要的。虽然15版中没有这项分析，但在我看来，这些因素很多依然存在，而且占比还不小。

需求分析的实践性非常强，因为面对的是用户，世界上没有两个相同的用户，所以我一般不太相信方法论。最近看了徐峰写的《软件需求最佳实践》，整本书并没有空洞的介绍一堆方法论，而是总结了很多作者自身的经验，还是值得一看的。这里我就借他山之石，摘录些个人觉比较好的观点。

需求可分为业务需求、用户需求、软件需求三个层次。

业务需求反映的是系统的高层次目标要求，通常由企业高层管理人员提出，通常体现在两个方面：

问题：解决企业运作过程中遇到的问题 机会：抓住外部环境变化所带来的机会，以便为企业带来新的发展。 用户需求是指用户使用软件需要完成什么样的任务，怎么完成的。通常是在业务需求定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。用户需求是需求捕获的产物，有以下几个特点：

零散：用户从不同角度、不同层面、不同粒度提出的需求，很多时候是一句话需求 存在矛盾：从不同角度去看业务，会有不同的需求，用户之间会存在不同的意见。 软件需求：正因为用户需求具有零散、存在矛盾的特点，需要分析人员进行分析、提炼、整理，从而生成指导开发的、更精确的软件需求。所以说，软件需求是需求分析与建模的产物。

软件需求可以分成功能需求、非功能需求、和设计约束三种类型

功能需求：对功能需求而言，最关键的地方是如何对其进行组织，传统方法大多按照程序的结构（系统-子系统-模块-子模块）来梳理，这样会割裂用户的使用场景。 现代需求理论强调分析人员从用户角度，将系统理解成一个黑盒子，从横向的使用角度来整理需求，建议使用RUP的用例方法。 非功能性需求：最典型有两个问题：一是信息传递的无效性，二是忽略了非功能性需求的局部性。 信息传递的无效性：诸如“高可用性”，“安全性”等需求，一定要有具体的指标来说明，否则这个信息是无效的。 局部性： “系统响应时间小于5秒”这样的话语要明确前提条件，系统在繁忙时段或某些复杂的查询，响应时间很有可能超过5秒。 设计约束：这块内容前期很容易被忽视，而且产生的后果往往比较严重。 之前给客户做过一个小功能，因为比较简单，也没太多重视，功能需求了解完后，直接就让开发做了。做完才发现客户需要支持IE8浏览器，而目前的框架并不支持。所以，只能重新选择框架再做一遍。 设计约束主要包括非技术因素决定的技术选型，比如我之前做的外包项目，用户指定要XX用框架，那就没有别的选择了。还有就是刚讲的预期的软硬件环境。想当然的认为用户都用chrome，导致了返工。