探索与分享软件工程中的创新
思考需求
是什么让程序员们“改改改”！是什么导致程序员们“拖拖拖”！是什么导致开发团队被奴役，陷入时间漩涡，使软件质量失控？总结一下也许能找到100个理由，恐怕其中有50个理由和需求有关！毫不夸张的说需求问题摧毁了整个软件。
我们需要的是一套完整的、正确的、一致的、可行的、无二义的、健壮的、必要的、可测试的、可修改的、可跟踪的需求。然而哪怕需求分析师们使出浑身解数，哪怕他们使用了“洪荒之力”，需求的变化不可避免，这个环节的变化导致其它环节更大的变化，在这些变化中导致的疏漏难以避免。为此我们可以采取两种措施应对。一种以不变应万变进行需求冻结，一种顺势而为进行需求补充。
需求冻结意味着生产资源按既定的方案进行分配，并推进生产实施。不言而喻，它的风险在于输出的成果与实际需求脱节，客户得到他不想要的或者是过时的内容。为了避免这种情况，把需求目标定义的足够小，然后快速完成必要的内容并交付。敏捷开发就是这样一个理念，通过小目标的迭代来完成一个大目标。然而这并不是一个完美的方案，过时的内容意味着生命周期结束，当整个项目没有结束时，就必须要替换已经处于生命周期结束内容，迭代变成了替换，也许就在替换过程中就出现了新的问题。如果采取强硬的姿态拒绝替换，那意味着软件的某些功能不足，质量受到影响。
需求补充并不是那么轻松。需求的确定需要经历采集、整理、测试、确认几个过程。需求的变更使得生产者要不断的在需求分析阶段投入资源，在实际生产中这样做恐怕会是难以承受成本投入。无疑这使我们陷入困境，难道我们对此就束手无册了吗？在中外各国的资料里没有找到答案，这就需要自已想办法解决问题！
我们需要对需求做一次需求分析。我国是一个高速发展的国家，这就意味着在政治经济领域的变化快且频繁。一党执政多党参政的政治协商制度使我国的政策延续时间较长且有累进的特征，政策转向发生在某些明显畸形行业里的概率较高，信息化尚属于发展阶段，对信息化产品的需求以内容为主。尚缺少核心的信息化基础软件产品，如操作系统，开发语言，驱动程序，虚拟化工具等。
在这样的环境下，软件需求普遍的矛盾在于对产品/项目的需求随时间变化可能产生变化，而需求文档只能静态的表达当前的需求；用户对新概念的产品/项目的认知不足，包括对它的内容、适用边界、操作界面、操作方式、成本及收益等，导致需求文档无法确切的表达这些内容。我们无法预测未来会发生什么事件，但从金融领域得到灵感，未来的发展趋势未必不可预测。因此无法在需求文档里体现变化的内容，但可以预估未来变化的趋势。任何产品都会有一个生命周期过程，在这个周期中它的成熟度会有一个规律性的变化。描述它的规律可以使用户比较直观的理解产品或项目本身。因此在需求文档里可以体现产品的成熟过程，以表达它的部分特征。从而使需求文档本身就能包容有限的变化。
软件的发展趋势或者成熟度变化都是一个种抽象的、模糊的的信息，如果用大段的文字表达这种信息，极有可能会使每个使用者各有各的理解。因为每个人的知识、阅历并不相同，对同一段文字所形成的思维模型出现差异并不奇怪。然而对需求文档而言就会词不逮理，这是典型的二义性特征。用尽可能简单的图表来表达，显然会是一个目达耳通的策略。不论是发展趋势还是成熟度变化，从逻辑上都是对“成长”的描述，这就为我们创建单一的表达方式创造了条件。
而我想到的最简单的方法是在需求理整阶段绘制一张“需求堆砌层次图”。所有讲需求分析的教材中都会提到“马洛斯需求层次理论”，这个理论所搭配的图就是一个层次图。这个图表达了每个层次的目标，层次与层次之间是一个直观的演进方向。把需求采集的内容整理成这样一张层次图，不仅表达清楚了需求目标，也显示出了需求演进。这为发掘潜在的需求提供了一种方法。
汉语的语言表达逻辑为建立层次图的过程提供了便利。需求归类为基础需求、期望需求、兴奋需求、反向需求，我把汉语词汇归纳行为词（通常是动词）、修饰词（通常是形容词）和目的词（通常是名词）。可以发现一个经验规律：在汉语构成了某一个需求描述中，修饰性词往往表达了期望需求和兴奋需求，目的词很大概率表达了基础需求，行为词则表达了需求点呈现的联系。而层次图中底层表示的是基础需求，顶层则有很大概率表达了兴奋需求，上层是对下层的演进。然而我们还需要发掘隐藏的需求，需求描述也许没有表达清楚实际目的，但描述信息则可能已经包含了实际目的的概念，因此把现有需求目的词抽象化用这种方法探测潜在的需求。抽象化可能产生多个概念，这些概念可能只有一个与实际需求有关，此时行为词呈现的联系就能帮助我们筛选出那个真正的需求。这就完整的构成了“需求堆砌层次图”。
如果有这样一个需求：
一匹跑得更快的马
| 需求描述 | 描述抽象 |
|---|---|
| 更快 | |
| 马 | 动物，牲畜，交通工具 |
能发现什么吗？
