如何进行有效的需求定义

在开始讨论服务和业务的需求定义之前，值得花些时间来理解一下什么是需求以及为什么需要“需求”。需求定义了客户/最终用户需要什么或者想要什么。需求定义了应该被满足的特定标准，有时还涉及使用需求或满足需求时的背景信息。

为什么我们需要需求？这是因为如果什么需求都没有，则几乎无法设计任何东西。如果你没有详细说明需要的是什么，那么你所得到的东西很可能不能满足真正的目的。如果你认真考虑了，那你怎么可能希望别人在不了解应该设计或交付什么东西的情况下去设计和交付这些东西呢？

很多人认为编写详尽的需求列表是浪费时间的。当需求写完时，事情已经变化了，编写的东西已经跟当前的实际有出入了。那为什么还要写呢？是的，编写详尽的需求列表几乎是不可能的，但是没有任何需求或需求不完整的话，同样不可能设计出完整的方案。定义需求还是一个跟踪和控制待交付内容的良好方法。管理变化的需求就像是对待移动的目标，但对于确保项目受控来说是必需的。

3.1.4.1 捕获需求

想想这样的场景：当你向某人询问需求时，得到的回答是“你有什么？”或“我想要这个方案”或“你有什么问题，去做不就行了吗？”。你上次遇到类似场景是在什么时候？从设计的视角来看，回答这些没有任何作用。但是，在开始服务设计过程时或开始项目时，经常发生这样的错误。设计一项服务或交付一个项目跟进入一个车展是不同的。你不能非常简单地去把你喜欢的东西拿来展示。就算你可以这么做，还是至少需要一个标准列表，通过它去度量你的选择。这些就是你的需求。捕获需求对很多人来说像是一种魔法，但是，对于成功地去设计一项服务来说，它是至关重要的。

从以前的经验可知，很多人都不知道他们想要什么。也就是说，他们不知道他们的需求。一个众所周知的捕获需求的技术就是提问开放性的问题，并从“什么（what）”、“怎么（how）”、“为什么（why）”、“谁（who）”等开始。封闭性的问题只适合做确认用。在捕获需求时，开放性问题可以让你得到更多答案。从一些答案中，可以引申出更多的问题，这些问题可以用来澄清需求或得到更多需求。对你问题的答案进行假设，并认为这些答案可能就是人们想要的，这不是个好想法。弄清你不确定的事情，会好得多。通常，这可能会打开一个全新的、你未曾考虑到的领域，并需要你去进一步探索。

因为需求一般非常抽象，所以，另一个确认/捕获需求细节的方法就是建立一个原型。粗略的模型让提需求的人可以看到实实在在的东西。这将有助于提出需求的人思考他真正想要的是什么，并进一步细化他的需求。原型还可以用来澄清他想要的系统是什么，以及怎样执行特定的任务。这对于提出系统或应用的需求非常有用。

3.1.4.2 良好需求的属性

很多人都认为编写需求是简单的，其实不然。编写明确的、可度量的、可测试的、真正描述出你的需要的需求，并不像你想象的那么简单。编写可测试的需求涉及很多参数的定义，需要对背景信息和可变性具有全面的理解。很多人过于低估了需求的重要性，以及定义需求所需的工作量。

不可测试、不可度量的需求是不太有用的，这跟没有需求也差不多。你怎样才能知道所设计和交付的方案是否是你想要的（满足了你的需求）？唯一的方法就是度量和验证它（测试它）。如果需求不可测试，你怎么去验证这个方案交付了市场需要的服务呢？比如，你的需求不能是这样的：“方案应该是可伸缩的”。这不可测试，你必须定义它是怎样伸缩的（比如在吞吐量是x时，支持最多10000个并发会话）。

在定义需求时，预定的方案经常变成需求。例如，在宽带服务中，你可以有这样一个需求：“服务应该在ADSL技术上交付”。然而，ADSL技术是一个实实在在的方案，而非一个需求。需求应该这样陈述：“服务当中，每个最终用户接入网成本应该少于xx美元，并且覆盖国家x%的人口范围，接入速度是x Mbit/s。就像你看到的那样，客观的描述和分析需求不是一项简单的任务。需求应该陈述出需要的是什么，而不是怎样达成或交付。(www.xing528.com)

很多人像定义功能和特性一样去定义需求，但是需求绝不仅仅是这些。开始时，应先思考一下非功能需求。在特定的负载下，执行特定功能时，系统的响应时间是多少？如果执行某项功能需要花费10min，则对系统用户来说可能就没什么用处了。我想这将给系统用户一个很好的借口去冲杯咖啡！然而，这是在浪费时间，如果系统中所有功能都需要这么长时间，那么可能让系统用户喝茶喝得都厌烦了！非功能需求的另一个需要考虑的方面就是参数及相关的取值范围。可能会有一个需求——“网络应该是99.9%可用的”，但是是在什么时间范围内呢？这是每个月度量一次吗？还是一年中的平均值？如果是每天的，那么很可能这是不可能完成的。非功能需求的另一个要思考的方面是易用性需求。如果最终用户需要在手机上按下10个不同的按钮才能使用它，那么这个特性就绝对会是没用的。因此，考虑非功能需求，而非仅仅是特性和功能性，这是很重要的。

一致性是定义良好需求的另一个属性。在需求背景中，一致性用来确保需求之间不会相互冲突。如果一组用户想要这样，而另一组用户想要的东西又有些许不同，就会发生冲突。例如，网络管理中心的一线支持人员想要某个网络告警在网管系统中被标记为“严重的”，而二线支持人员只希望此告警是“重要的“。让不同的用户组对需求达成一致，并不是一件容易的事情。然而，冲突的需求也是不能接受的。

最后，需求应该是现实的。拥有一个不会被实现的需求，就没什么用处了。如果服务要达到某个愿景目标，那么这个愿景目标不应该被捕获为需求，而是应该作为一项信息描述被记录下来。

3.1.4.3 其他需求属性

当定义和编写需求时，为需求编号并描述需求来源（即需求是从哪里来的）是有用的，有时甚至是至关重要的。对需求编号有助于如下任务：引用需求、设计的顺从度描述、测试覆盖情况。需求跟踪就是：记录需求来源，在开发生命周期中跟踪需求变化。如果你拥有非常大量的需求，并且存在需求冲突，那么需求跟踪是非常重要的。把需求来源存放在编写需求的人的头脑中是不够的，特别是当需求来源于“对业务相关的许多人所作的访谈”的时候。让人记住所有需求的来源几乎是不可能的。另外，如果不知道需求的跟踪关系，那么在开发过程中，任何人都很难去管理这些需求，因为没有人会知道需求的哪个部分变化过了以及为什么发生变化。

最后（但也很重要）是需求排序。每项服务都有很多需求。一般地，实现所有需求是不可能的。那么，哪些需求是本质的（也就是“必须有”）？没有它们就没有服务。还有些需求反映了某些所需的特性，但是当服务没有它们时，仍然可以正常工作（也就是“应该有”）。当然，还有一些需求是“最好有”的。对需求排序的时候，不能拖泥带水，而且必须用一致的标准进行。很多需求开始看着可能很重要，但当你真正仔细考虑它们（如果这个需求没有实现会怎么样？）的时候，经常发现它们并不像开始想象的那样重要。

正如你所见，需求捕获、分析和归档是一项主动性的工作，并且经常是繁杂而枯燥的——但它非常重要。人们必须考虑到所有相关方面的问题。确保所有需求都被捕获了且没有漏掉，这并不容易。很多人只是认为编写需求是很简单的，然而这种想法却是很多问题的根源。编写需求是一个交互的过程。毫无疑问，需求会随着时间变化。因此，拥有一个好的变更控制和跟踪过程来确保原始需求的清晰，使得变更被跟踪、需求被有效管理，这是非常重要的。建议使用需求捕获工具来记录所有的需求及其优先级。这会使得需求的跟踪、管理和变更控制更加容易。

需求定义、管理和跟踪的课题已经结束。如果想了解此课题的更多内容，可以参见参考文献[20]《Software Requirements Styles and Techniques》和参考文献[17]《Software Requirements》。关于需求定义的标准可以参见参考文献[18]《IEEE Recommended Practice for Software Requirements Specifications》。

看了上面的内容后，你要怎样定义需求呢？你从哪里得到需求？首先，对于多数的服务而言，需求从服务描述中来，服务运营需求（operational requirements）来自相关的业务。因此，拥有一个完整定义的服务描述，对于开发该服务是很重要的。其次，我发现需求很少是摆在你面前的，你需要自己去寻找它们。捕获和定义需求的最有效的方法是向正确的人询问很多开放性的和探索性的问题。因此，在本章的后面部分，我将提出很多问题，进而启发你去识别和定位出潜在的需求。