在前面的文章中，我们重点阐述了需求工程与软件开发的地位关系（下图），讨论了需求复杂性的原因，也给出了设计思维这样的小技巧。

今天，我们聊聊需求本尊，看看咱们对这位“大神”到底了解多少。你觉得需求是个啥？

既然软件是用来解决客户在现实世界中遇到的问题的系统。那么软件项目中的需求，便是解决客户在现实世界中遇到的问题。问题源自现实与理想的差距（百度百科）。

既然是理想，就很有可能是不明确的、不具体的、不完整的，甚至是不切实际的。我们在需求工作中，遇到客户说不清、变化甚至矛盾的，就说得通了。可是理解归理解，项目还是要最终交付的，成本和进度也是有限的。客户理想那么缥缈，那咱们现实的日子怎么过下去呢？

约翰·冯·诺依曼（John von Neumann）和奥斯卡·摩根斯坦（Oskar Morgenstern）在《博弈论》中写道：“There is no point in using exact methods where there is no clarityin the concepts and issues to which they are to be applied”。应用到需求问题上，可以概括为一句话——在弄清楚需求本身之前，啥方法都不好使！

这就很明确了，想要做好需求，必须弄清楚客户的问题与期望，详细梳理和分解需求。

环境问题的存在，会直接作用于具体问题与目标问题。总的来说，现实世界的问题主要体现为执行层问题与决策层问题两种。

值得一提的是，还有一种不得不提的，叫“不切实际的期望”，可能是目标期望，也可能是任务期望。有两大类型：① 不可行（技术上无法实现、存在风险与隐患）、② 超出合同范围（预算、周期、产品与服务内容等）。

我们在《直面需求问题的鸿沟》一文中提到，需求工程包含系统需求开发与软件需求开发（上图）。系统需求可能发生在售前阶段，此时我们要识别出不可行的，在合同中加以规避。而售后阶段，“不切实际的期望”主要表现为超出合同范围这一类型。一旦发现，不要盲目答应或拒绝，而是应将问题分析清楚，上升至更高管理层进行决策。如果高层管理者出于战略考虑，答应了客户这种超范围的期望。那么，PM应该理所当然地变更项目计划，比如延长时间、增加资源、调整工作任务及其优先级、调整风险计划与应对措施等。

项目需求主要是对项目重要活动和目标的期望，包括了工作任务、进度计划、成本、资源等。比如开发一个大数据系统，成本50万内，5个人，3个月完成，100个功能模块；除了软件产品，还需要编写用户手册1份，为客户提供试运行前培训1天等。

而过程需求主要是对实现项目需求的软件开发过程的期望，包括所选用的生命周期模型、过程中产生的文档等。比如选用敏捷开发模式；先由PO召开策划会议，编写与沟通Product Backlog、估算工作量、确定Sprint Backlog、制定DoD；再进入Sprint开发；每日站会，更新与记录Sprint与Product的完成情况，记录和处理存在的问题与风险；最后评审与回顾满足DoD的产品，分享过程中的问题与经验，彼此学习，沉淀经验……

需求结构图 - Fancier凡奉信息版权所有

我们将各种不同名目的需求，按照产生的原因与时间顺序，整理出了上面的需求结构图。纯软项目中，我们通常会将主要的关注点放在软件需求上。但是，这仅仅是“系统行为”中的一部分，距离客户的期望与问题都还很遥远。而给项目带来巨大麻烦的那些需求问题，其实主要源自上图中的其他部分，更贴近客户的期望与问题。

经过上述的分析，我们可以看出，软件需求是为了解决客户在现实世界中遇到的问题，满足客户对解决这个问题的期望，从而产生的对软件系统以及实现软件系统的要求。这与IEEE对软件需求的定义如出一辙：

1. 用户解决问题或达到目标所需的条件或能力。

2. 系统或系统组件为满足合同、标准、规范或其它正规文件所需具有的条件或能力。

只要你的项目不是很少人参与、很短周期、很简单。上述林林总总的需求，总要清晰地记录并传达给项目组的全体成员。因此IEEE对软件需求还有第三条定义“一种反映上述a)或b)所述条件或能力的文档说明”。

日后的工作中，大家可以对照上述方式，厘清客户的问题，梳理客户的期望，得出满足客户的、全面、完整且正确的需求。以此，指导项目的前期策划与后期执行，并在不断经历的项目中，提高应对不同类型需求的工作能力。