引言

需求分析阶段需要经历两个步骤：首先，提出问题的人说一些话，以告诉帮助他解决问题的人他要干什么，这就是“问题陈述”，即通过语言或者文字对某个关注点的细节进行表述。然后，解决问题的人和提出问题的人进行沟通，以确证这个问题的细节，这就是“探索需求”，这是一个反复沟通的过程。

需求分析在现代软件开发中的地位日趋重要，这也意味着我们认为现今的需求过程尚不完善。这种不完善很大程度上体现在“问题陈述”和“人们真正想要的东西”之间的差距上，或者说，“问题陈述”没有能够陈述清楚“人们真正想要的东西”。

在过去几年，软件过程和软件工程流行的时代，很多人已经被时尚所左右，言必称自动化，开口即软件工程，仿佛所有的开发问题都已经解决。更有甚者，有人还认为需求分析中的歧义的根源是因为“人”的参与。有人认为“人”的不确定性导致了“陈述”的不确定性，由此导致了“人”提出的“问题陈述”的歧义。并且，他们认为只要排除掉需求分析过程中的人的因素，然后用一种严格论证、高度自动化的、规范的方法论来进行分析，就能够消除这种歧义了。

但是，我们无法“剔除”具有严重不确定性的“顾客”；同样，我们实在不能不把顾客当人看待的。

自动化方法干的是“大事情”。40年前需要很多个星期才能完成的工作量，今天只需要一个小时就能够搞定。而且，由于自动化工具的发展，我们还开始挑战那些在以前想都不敢想的系统。然而，随着工具的进步，软件产品在可用性方面的口碑却并没有多少提高。

对于那些需求明确、陈述无歧义、一定程度上模式化了的内容，自动化方法非常擅长；但是也还有一些涉及到人性心理方面的棘手问题却无法用这些方法来解决。换句话说，只要是有规律的、统一的开发过程，自动化方法非常擅长；而在不同项目或产品之间的差异和个性化，则需要更细致的分析。

我们不妨做一个简单的计算。

规模为S的项目中有P%的问题为公共问题，有Q%（Q＋P＝100）的问题为个性问题。

在时间T1时，我们每解决一个公共问题需要投入T，每解决一个个性问题需要投入M。解决个性问题在整个项目中所占的投入为：R1＝M×Q／（T×P＋M×Q）。

在时间T2时，我们每解决一个公共问题需要投入t，每解决一个个性问题需要投入m。解决个性问题在整个项目中所占的投入为：R2＝m×Q／（t×P＋m×Q）。

从T1到T2，自动化水平提高了，于是有T>>t，公共问题和个性问题的比例变化很小，而且对于每个个性问题的投入也变化很小，即有M≈m。从而可以得到R1<<R2。

这表明，随着自动化水平的急剧提高，我们在个性问题方面的投入比例也急剧提高。

个性问题，亦即是人性方面的因素反而随着自动化程度提高而愈显得重要了。这一特征在那些具有多年开发经验的人们当中早已成为了共识。也就是说，经验丰富的专家们在技术任务上的投入少了，而在人性因素方面的投入更多了。

语言和符号系统

语言是我们表达思想的工具，也是某种文化的载体。在开发系统方法中，我们也有语言，那就是符号系统。相信所有人都遇到过因为语言不通而产生的交流障碍；同样，在符号系统上，我们也遇到了交流障碍。

语言文字所传递的信息包括“内涵”和“外延”两部分。人们在说话传递信息时，往往会附加上各种语态、表情、动作作为对其所说语音的外延；甚至我们可以认为，因为我们来自各个不同的省份县市，各种不同的方言乡音也传递了丰富的外延。

于是，对于同样的事件或需求，我相信没有任何两个人的描述是完全一致的。承认这一点对于我们直面需求分析的困难会有很大的帮助。

我们这里给出优秀符号系统的两个重要要求（当然这仅仅是众多要求中的两个），以帮助我们将来使用这些符号。例如说，首先符号系统要能够比较全面地表述我们所遇到的绝大部分问题；其次为了适合产品开发的过程化，符号系统的表述结果要比较容易保存和修订。这也是对一个优秀的CASE和CAD工具的基本要求：在任何时候都可以保留并修改我们当前的结果。

实际上，几乎所有的符号系统本身是不可能完全“直观”和“易读”的。

如果，要让所有相关人员都能够理解某种符号系统，那么，最直接的办法就是培训这些相关人员。下面的步骤可以测试一下当前的映射图到底有多直观：

1. 把每一幅映射图展示给那些不知道这种符号系统的人来看。这种方法能够揭示出符号系统中不直观的地方。当然，也有可能揭示的是这个映射图中需要表达的那部分信息本身的不直观。
2. 让每个人用自己熟悉的符号系统重新描述一遍对映射图的理解，然后再让一个理解这两种符号系统的人来核对。这样可以揭示映射图中的一些人为的假设。
3. 使用某种能够把别的符号系统自动转换成某种“标准”的符号系统的自动化工具。

上面讲到了因为不同的符号系统导致的对映射图的理解的分歧，这就相当于由于语言不通而导致了交流障碍。最直接最常见的办法就是推迟需求工作的进度，先让大家都来学习这种语言（或符号系统）。但是，这也是不切合实际的，因为这样有可能还会让大家失去对需求过程的兴趣和冲动。经验表明，把这些学习时间安排为需求阶段的一部分会好一些，因为这时候我们可以一边学习语言，一边解决问题。

特别地，我们需要指出，任何一种符号系统都不可能百分之百地反映需求。下面提出了一些关于如何让开发者较好地表述需求的语言的建议。

1.  在生活（或开发项目）当中，我们往往会遇到一些不明是由的旁人（非专业人员）横加职责，他们往往不愿意或者不屑于花时间来了解设计过程的时候，这时候，建议雇用一个明白事理而又口齿伶俐的调解人会比较有效。
2. 人们不愿意参与设计过程的一个重要原因是现在的所谓“专业设计人员”的高高在上的姿态。千万要注意顾客和旁人（实际上是决定事态结果的裁决者）仅仅是对开发过程不了解，他们在别的方面（比如说法律、业务等）却是专家，这也是需要他们参与的原因。
3. 一部分自动化过程的固执而忠实的拥趸认为他们的“直观”的符号系统很容易被别人看懂。这时候，不妨让他给小组里外的成员培训一下他的符号系统。
4. 对于同一个需求过程中的两批不同背景的专家，常常会倾向于说两种不同的符号系统。那么最好的办法就是用两种不同的符号系统都表述一遍。
5.  用一种大家都能听懂的语言来作为正式文档的语言会比较有效，那么在需求过程中也最好事先指定一种“大家都能理解的”符号系统作为正式文档。如果谁不懂的话，就让他去学好了。
6. 不同母语之间的翻译会有优劣之分，同样不同符号系统之间的翻译也有优劣。优劣的背后就是分歧，也就是歧义。需求过程经历了从真正最终用户——用户代表——需求分析员——需求规格说明书这么一长串的步骤，每一步都是一种翻译，因此保证每一个步骤都是最优的就显得格外重要了。
7. 需要注意的是，需求过程并不完全是瀑布式的。随着过程的深入，我们极有可能会像老牛一样进行反刍。

含混性的形式和来源

无论什么时候，如果人们仅仅使用那些忽略了人性因素的自动化工具，就绝不可能完美地描述需求。而且，含混性随之而来，看起来整整齐齐的需求规格说明书可能会带来各种各样的解释。

我们认为，含混性有多种形式，比如：

（1）表意不全。也就是说，这种需求陈述缺少很多必要的产品性质描述。例如，对于某种方案的使用方法、耐用性、成本，对这种产品的大小、形状、重量、寿命，以及对于这种东西可能应该包含的功能、所处的物理环境、文化氛围等等都是需求陈述中非常重要的组成部分。

（2）表意不清。用词含糊是含混性的重要来源。尤其要注意一些模糊概念的词汇运用，比如说，大、小、多、少、非常、很，等词汇都非常难以度量。

（3）理解者自以为是。几乎世界上所有的人都拥有他们对某些认识上的成见，而视那些不同看法为偏激或是钻牛角尖。人性的弱点让他们自以为是地代表了大部分人的意见，从而把自己的偏见当成了共识，最终陷入真正的误解。

需求中的含混性，在有经验的开发人员眼里，无疑就是开发过程中需求不断扩展、进度不断延期、质量不断下降、可控性不断落空的罪魁祸首。

软件工程经济学》的作者Barry W. Beohm同志通过对63个软件开发项目的研究，得出了下面的表格，不妨一读，右边的是表格对应的柱状图，不妨一看。

为了修正一个错误，所要付出的成本

尽管上面的表格已经能够生动地说明：对于任何一个错误，如果能够在需求阶段发现它，那将是多么地节约成本啊！但是，专家说了，这些数字还是很保守的，因为Beohm同志研究的项目都已经完成了，也就是说这些数据中还没有包括至少1/3的没有完成的项目，而这些夭折的项目很大程度上都应该“归功于”需求分析。

几十年来的经验表明，那些错误的、失败的或灾难性的项目让投资者付出了巨大的代价，而这些项目中的大部分都起源于含混的需求。多数持有某种信仰的人或理想主义者会认为，这个世界上存在着完全确定的东西；当他们筹建一个项目的时候，就把项目要求看成了确实存在的标准。现在，我们接下来他们提出的项目，那么，这一项目要求就成为了我们获得的需求陈述；不幸的是，这一需求陈述在绝大多数情况下是含混的。

虽然我们在很多时候祈祷上苍的保佑，但在具体实践和委托别人做事的时候，我们总会希望所用的方法是科学的。于是，对于那个存在于理想主义者心中（或者是天堂）的需求陈述，也最好遵守一些科学的准则。

这里我们就要说明，需求探索过程是一个渐进的、可以逐步测量的过程。而我们的假设就是，我们的所有相关人员当中，的确相信存在着某种明确的需求，并且大家愿意一起来找到它们。

需求探索过程就象是“历险”。为了避免含混性，我们要随时提醒自己：

1. 我们不喜欢含混性的原因是含混性需要成本；我们认为含混性发现得越早越好，是因为越早发现成本越低。
2. 时刻反省自己，反省自己在需求过程中的含混性，反省自己被这种含混性所带来的困扰。如果你发现产品并不完全如你所想，你可以问问自己：“是什么需求让我们制造了这样垃圾的产品？”

在需求工作中，会有若干种含混性产生，主要表现为：１）观察错误和回忆错误，因为我们每个人的观察能力和关注点都会有所差异，因此，任意两个人都不一定会看到完全一致的东西（观察错误），或者完全一致地记住他们所看见的东西（回忆错误）。２）理解错误。３）问题描述的含混性。

其中观察、回忆和理解错误，都与观察者自己有关；而问题描述的含混性，则与表述者有关。这就牵涉到我们前面说过的符号系统。

找出含混性来源的办法推荐如下：

1.  对参与者进行需求文档某些部分的解释进行提问，并把相近结果归成一类。
2. 通过询问每一类中的人们的想法来分析对每一类的理解。
3. 同一类内部的差异来自于观察错误和回忆错误。
4. 为了辨识各类之间的差别，可以请参与者回忆那个他们认为的被问的问题，当然不能给他们再看一遍。这个种方法能够找出解释错误。
5. 通过对观察、回忆、解释错误的分析，找出问题描述中易犯上述错误的地方，修改它，或者做一些详细的注记。

善用工具来降低需求中的含混性

人往往如此；当你了解、学会、掌握、熟练了一种工具之后，就很难接受别的类似工具；而对于那些本质上并不类似的工具，人们也会自然地产生排斥心理。我们知道，每一种工具都有它的针对性和局限性。那么，为了很好地完成需求开发，我们一样需要有专门的工具和技术；针对于需求分析中的某些关键点，我们还需要对之进行更深入的研究。目前市面上有很多很多的项目管理的工具、方法以及软件，是否只要使用好它们我们就能一路顺风了呢？

我们认为，掌握各种各样的工具是很不错的主意；而且，如果你想很好地做好需求工作，最好能很好地把握直接的提问、面对面的观察和谈判技巧。但是，出于对工具局限性的担心，我不得不提醒读者再次注意人类思想的复杂性和含混性。我们常常会看到一些理想主义的需求分析员编制各种各样的表格和调查问卷，然后根据表格里面的文字和数据来撰写他们的需求规格说明书；这一节就是要说明这种死板的方法是不能够完全正确地获得需求的。

我们常常通过问问题，根据回答建立目标产品的各个属性，以构建产品的决策树。

理想主义者认为只要每一个选择都由用户判断，每一个决策都经过用户签字，那么他们的决策树很快就能找到真正需要的产品。其实我们就算是能够作到每个判断的正确性和明确性，也会给我们的决策带来了严重的压力，每一个分枝的地方都会有明确的用户配合吗？另一方面，我们不可避免会加入我们自己的“经验”，实际上是我们的假设。

首先需要说明的是，决策的次序非常重要。比如，如果客户想要一辆绿色自行车，那么如果给他一辆橙色自行车可能会比一个绿色卡车来得比较容易接受。因此，问题“它是什么颜色的？”和问题“它是自行车还是卡车？”相比较而言应该问得较晚。次序的重要性还体现在它能够减少我们为错误决策减少修复误差。

我们说，我们需要一些额外的工具和技巧来降低含混性；这是因为“我们常人并不擅长于发现我们已经忽略的东西”。这种心理学上的观察结果实际上严重地困扰了我们这些设计者。例如说，我们无法用肉眼看到X射线，我们无法用自己的耳朵听到超声波，我们无法步行漫游世界。

在降低含混性方面，我们需要注意以下内容：

1. 分歧无处不在，设计者最容易自以为是地认为他们心目中的解决方案就是客户想要的，而实际上这往往给客户强加了很多假设。即使我们发现我们的解决方案远超过客户所知，千万不要过度自满，要么去说服他们，要么去寻找能接受你的方案的新客户。
2. 直接提问时，可以使用决策树。但是千万注意对每一个问题的回答进行一次口头的和书面的确认，即把客户的回答写出来给他们看，这可以锻炼你的文字表达力，也是降低含混性的技巧。
3. 有责任的需求工作者接受我们的思想，但是他们开展工作的困难不止来自于客户，也会来自于他们的那些守旧的同事。我们必须说服这些人，最好的方法就是举一些你们共有的失败的例子。不过千万注意不要让对方难堪。
4. 理解并接受自己的局限性，同样也理解并接受客户和同事的局限性。