需求工程？？？

需求工程？？？
邓 辉
软件是一种商品，既然是一种商品，就必然要满足购买者的需要。是的，人们是不会为那些不能满足自己需要的东西付钱的。另外，开发软件是需要成本的。只有那些成本低，并且能满足客户需要的软件产品才能够为软件企业带来利润。因此，要想使软件能够为软件企业带来最大的效益，一个首要的前提条件就是要弄清楚客户需要的到底是什么，也就是说，要搞清楚用户需求。弄清楚了用户需求，不仅可以使得所开发出来的软件确实是用户想要购买的，并且还可以避免由于开发那些多余的特性而造成的成本增加。开发出符合需求的软件是每一个软件企业在市场竞争中取得胜利的最为重要的条件。
于是，许多软件企业就把软件开发活动中和需求相关的活动放在了最为重要的一个位置上。这些企业对项目成员进行了大量的需求获取、分析、记录方面的培训，试图以工程化的方法规范需求的开发，甚至专门成立了一个独立的需求开发团队来为项目的后续开发提供一个稳定、清晰、明确的需求集。重视需求这种想法本身是非常正确的，遗憾的是，很多企业在把“重视需求”这种理念落实到具体的实施中去时却犯了很多严重的错误。这些错误足以使“重视需求”成为一句空话。下面，我们来对这些严重错误逐条进行分析。
错误认识一：试图预先固化需求
“软件需求无法预先固化，并且随时可能发生变化”已经是现在整个软件工程界的共识。但是，还是有很多软件企业试图在项目开展实际的开发工作前固化需求。为什么呢？因为如果能够在实际的项目开发前把需求固化下来，那么就会大大降低以后由于需求变化带来的各种风险和问题。然而，无数的实践表明，在捕获需求方面，无论你多么的刻苦论你多么的一丝不苟，无论你做多么什么的思考，无论你付出了多少努力，需求总是会变化的。
需求的易变性是由激烈的市场竞争和软件本身的特性决定的。客户企业很少会在软件交付的那一刻还保持原始的需求不变。客户企业要想在激烈的市场竞争中生存下去，就必要根据市场的变化来调整自己的业务流程，而这种变化就相应地反映到所需要的软件当中。另外，由于软件的不可见性，有时客户自己都不是非常清楚自己想要的是什么，就更不用说把需求明确、清楚的表达出来了。在大多数情况下，只有在见到了真正运行的系统后，客户才知道自己想要的到底是什么。
因此，当我们在项目进入实际的开发之后发现需求变化时，不要再发出“需求没有做好”这样的感慨了。因为易变性是需求的根本特性。如果真要重视需求的话，首先就不应该试图在一开始就把固化下来。重视需求是一项持续的活动，试图预先固化需求的做法其实是一种偷懒的行为。
错误认识二：需求的记录必须要规范、详尽
这句陈述本身没有错误，如果需求是以规范形式记录的，那么其他人就会比较容易理解，这样也有利于交流。这里很关键的一点是，你什么时候去规范地记录需求，也就是规范地记录需求的时机。很多需求分析团队总是试图一开始就以use case图的方式记录需求。谈论的内容也往往是形式多于实质。他们在preconditions、postconditions、actors、secondary actors以及许多在目前阶段根本不重要的事情上讨论的火热。
其实对于use case说，最为重要的一点就是要保持简单。在一开始根本无需关注形式，随意地记录下来就行了。也无需过多地关注细节，细节只有到了后期才有用。更不要试图去记录所有的use case，正如前面所述，这是一项不可能完成的任务。因为需求很可能会发生变化，正因为它要变化，我们根本无需一开始就记录下它的细节。捕获需求的细节应该在一个合适时机，一般来讲就是“在开始实现该需求的前几天。”而最为规范、准确的需求就是可以自动运行的验收测试用例（这些测试用例完全可以以客户非常容易理解的语言编写，这取决于是否真正重视需求），这些测试用例不但非常精确地描述了系统应该完成什么功能，而且还验证了这些功能是否被正确的实现，并时刻和实现保持同步。
那些一开始就以非常规范的形式、非常详尽地记录需求的做法，最终只会产生一些和实际需求完全失去同步的文档。这样的文档有什么价值呢？
错误认识三：需求的分析和实现是独立的活动
“需求的分析和实现是不相干的活动”这句话听起来好像没有什么问题，需求的获取和分析是要搞清楚“要做什么”，搞清楚后做（实现）就是了。不是吗？问题没有这么简单。
要想真正地把需求搞清楚，和客户频繁、有效地交流和沟通固然重要，但是从交流和沟通中得到的信息只能作为一个大概的需求。要想真正把这些需求弄清楚出来，就必须去实现它们。只有在实现中，很多东西才能明朗。只有在实现中才能加深对需求的理解，甚至启发出新的需求，帮助客户取得优势，获取双赢。只有在实现中，才能发现更好的需求分解方式，从而使得整个系统的架构朝着更好的方向演化。
所以说，“弄清楚需求”是一项持续地活动，是一项测试驱动、反馈驱动的迭代式活动。那些试图把需求分析限制、固定在某个阶段的做法，根本不能称之为“重视需求”的做法。
什么才是注重实效的需求工程？
 判断某项活动是不是符合工程化的做法，并不是以该项活动的结果是否以某种规范或者流行的方式来描述和记录为标准的，更不是以在描述和记录中出现多少专业名词为标准的。那些一开始就试图固化需求、并用“规范、漂亮”的use case图来记录需求的做法不是工程化的做法，那些试图把需求的分析和实现完全隔离的做法更不是工程化的做法。判断某项活动是不是工程化的首要标准应该是：该项活动的过程是不是符合它所涉及的领域的基本规律。只有符合了领域的基本规律，才能真正的降低这项活动的成本和风险，才是真正的工程化做法。
 对于软件领域来说，我们在进行需求方面的活动时，就必须要按照软件本身的特性和规律办事。和其他领域相比，软件的最为独特的特性就是：几乎无成本的构建和可逆性。正是这两个特性使得我们无需像其他领域那样在前期投入大量的精力和资金去证明所作出来的产品是正确的、可靠的（想想飞机工程中的大量原型试验、风洞试验等）。
是的，我们无需去用程序证明的方法去证明软件是正确的，确实也没有任何一个软件企业会去这么做，为什么呢？因为我们基本上可以无成本的把软件制造出来（compile、link），然后去验证结果，如果有问题再更改软件（可逆性）。这里的验证是必需的，是为了证明程序是否按照期望的行为运作，这是一个探索、加深理解的过程（在这个过程中，很有可能发现对需求的理解错误）。我们越早的开始这个过程，越频繁的实施这个过程，就越能够降低软件开发的成本和风险。那些试图一开始就捕获、固化所有需求并把分析和实现隔离的做法，才是非常高风险的做法。
 另外，软件代码的编写并不是一件无足轻重的活动，相反它应该是整个软件开发活动的核心。因为代码的编写不是一项体力劳动，而是一项集分析、设计、实现、改进、验证于一体的综合智力活动。正是在这个活动中，我们才能加深对需求的理解，甚至可以说是真正理解需求。正是在这个活动中，我们才能使得软件具有更好的可逆性，从而进一步简单软件开发的成本。我们的项目开发人员在学习沟通、交流技能的同时，更要加强软件技术方面的技能，只有这样才能更好的挖掘出埋藏在需求底层的抽象，才能做到需求概念元素和设计实现元素间的一一映射，才能使得我们的程序更加模块化，更加具有表达力，更加易于维护和扩展，更加具有“软”性，从而为迎接需求的变化打下一个良好的基础。
 C++之父Bjarne Stroustrup在设计C++语言时，坚持这样一个哲学观点：“尊重一个群体而不尊重这个群体中的每一个个体，那么尊重这个群体就是一句空话。”同样，重视软件质量、重视软件需求，但是却不遵循软件本身的特性和规律，忽视需求获取活动的特性和规律，不重视组成软件质量的一句句代码的质量，那么重视软件质量、重视软件需求也是一句空话。
 因此，我们在进行软件开发活动中，如果在关注形式和过程的同时，更多地反思一下这些形式和过程本身的质量，更多地关注一下如何才能提高真正的软件质量――可以更快、更好地满足客户的需求，使客户满意，而不是软件开发活动是否严格符合某个过程。并把这些关注真正落实到日常的每一项活动之中，这才是真正注重实效的工程化方法。