关注需求，我们到底需要关注什么？

需求具体包含些什么

虽然我们每个人都在谈论“需求”，但是“需求”到底是什么呢？我们需要关注需求，但是抽象的“需求”到底包含哪些具体方面呢？我想，这是值得我们每个人，特别是分析和设计人员关注的问题。

从高斯和温博格《探索需求-设计前的质量》一书中，我们大概可以得到一些启发：在关注需求的时候，我们需要关注几个具体方面，也就是功能，属性，约束，偏好。

功能和属性大家应该都很熟悉指的是什么。一个软件产品，人们之所以需要它，是因为它有某些功能。而为了满足用户在功能上的特定需要（比如感观上的，性能上的），我们必须让产品有一些属性。

至于约束也很好理解，产品具有的属性必须是什么，这就是约束。比如产品必须支持键盘（无鼠标）操作之类。实现某些功能时候，也会有一些约束，比如权限控制之类的。再比如，产品的稳定性（MTBF之类）必须达到多少。

“偏好”所指的是对于属性一些实现，这些实现不是必须的（所以产品没有这些属性用户也可以接受），但是如果实现了就可以提高用户满意度的一些条件。比如《探索需求-设计前的质量》中曾经举了一个（可能是）很惊人的例子：在某些产品中，开发时间是一个约束，某些产品中，开发时间是一个偏好。

你在正确地探索需求么？

看到这里，你也许会问：说了这么多，本文作者到底想说明一个什么事情呢？其实我更想问一个问题，也就是：在你的需求工作中，你是否真的完全在这几个方面得到正确定义了呢？你探索需求的方法正确么？

用例建模时我们可能会忽略的方面

可能现在很多项目都在使用用例进行建模，用例是好的，但是用例对于功能的强调容易让人忽略需求的其他方面。单纯的用例图反映出来的信息就更加可怜了。

书写过用例文档的人可能印象最深的就是那些按顺序编号的成功场景，分支流程之类的。这些功能要素是这样重要，以至于我们经常忽视了用例的其他部分。你的用例文档中各种约束条件是不是经常只有寥寥数条，比如“用户必须已经登陆”之类的呢？你的用例文档中是否有“用户愿景”或者类似的部分么？你的用例文档中能够反映出用户的偏好么，还是仅仅说明了那些你觉得最主要的约束条件，或者约束条件一栏仅仅是说明了对影响功能执行的约束，而缺乏对于属性的约束呢？

当然我们必须承认，产品的功能是用户最关注的方面，因为它是用户掏钱购买软件的原因。但是对其他方面的忽视可能导致软件的失败，所以我们不能够忽视他们。

我们怎么获取它们

获取信息是一个大问题。用户听不懂我们的语言，而我们也不知道他们到底在想什么。我们怎么才能知道他们在想什么呢？我想最关键的，必须站在用户的角度进行思考，思考他们所描述东西的出发点，如果说得更加专业，更加简明一点，那就是明白他们的“愿景”。

很多时候，会有类似这样的情况：需求人员问用户说：“你真的觉得这些报表就已经足够了么？”用户说：“我想应该差不多了。况且我现在也想不出别的东西来了。”于是产品投入了开发。一段时间后，用户突然急匆匆地跑过来说：“我觉得我们还需要再增加一张报表。”于是两个人吵了起来。

我们到底要探索什么

我们所要探索的，不仅仅包括用户所说出来的东西，还有他们说出来这些事情的动机。如果你自认为是一个合格的需求分析人员，你就应该认真的站在用户的立场上和用户探讨，我们为什么需要这些需求，隐藏在背后的是什么样的愿景，为了实现这些愿景，我们还需要些别的什么东西。

增加需求的人都是傻瓜？

有人会嘲笑这种做法。软件公司都在急着赚钱，用户想不起来的一些功能，即使有时候需求人员想到了，他们也会故意不说出来。为什么呢？不说出来的人有他们的理由：难度在客户支付同样费用的时候，需要开发的功能不是越少越好么？

这句话可能有道理，不过前提是你能永远（起码在客户付钱以前）不让他们提出来这些事情。客户有钱可以做很多事情，为什么他们非要把这笔钱花在软件项目上呢？是因为我们的软件能够帮助他们解决一些问题，这些问题借助于我们所说的“功能”完成。如果我们的软件帮助他们达不到这样的目的，最后的结果肯定是不欢而散。

而需求是由愿景决定的。如果产品只能够实现部分需求（另外的一部分或者被隐瞒了，或者尚未被发现），那么愿景就没有达到满足，总有一天用户会突然明白产品还欠缺一些功能。这一天可能已经是产品交付后在进行试运行了，而这个时候再次修改产品，你会付出更大的代价。而如果你不修改，客户会和你闹到底。做需求分析的人一定要明白：耍小聪明的人最后一定会得到惩罚。

所以，不要心有旁骛，踏踏实实地深入到用户的心中，探索他们究竟希望产品会成为什么样子。

需求会不停地变化，这是因为用户的愿景没有被正确定识别

“用户的需求总是在变”，这是我听到我们各种软件从业人员说的最多的一句话（从管理层到技术人员）。我的看法略有不同，我觉得：需求变化的原因，很大程度上是因为我们根本就没有识别什么是真正的需求。

你可能会问：有真正的需求，难道还有假的需求么？我想起码可以这样说：有一些需求仅仅是一些表象，由于我们没有触及到掩盖在这些表象下最根本的愿景，它们就很可能会不停的变化。需求调查的对象是各种各样的用户，而用户也只是普通的人（和我们一样），普通的人就有脑子模糊的时候，而且每个人的知识也具有局限性。

比如用户说：我们需要系统能够打印这些销售统计。为什么需要打印这些数据呢？用户继续说：因为领导需要看。为什么领导要看这些数据呢？因为他需要决定下一期生产量的计划数。所以领导需要决定下一期生产量才是真正的需求，而“打印销售统计”只是一个表象而已。如果我们仅仅实现了“打印销售统计”的功能，那这个需求很可能会变化，因为销售统计数字可能并不足以成为下一期生长量的决策依据。

如果我们正确识别了用户的愿景，那么我们就可以从他们的角度出发，探讨到底什么是最合理的解决方案。这样的解决方案是稳固的，因为它有牢固的根基。

实际上，真正的需求可能会变化，但是这是和用户所处的市场或者环境相关的，或者用户的经营决策有变。但是这种变化的几率并不大。如果用户的处境和他本身的决策都没有变化，而需求却发生了所谓的变化，那就说明我们没有明白到底他们想要的是什么：我们可能仅仅看到了表象。