需求模式探索

最近改行专做需求分析了，所以决定在需求领域再下一番功夫。由于问题域的不同，通常我们无法找到类似于设计模式的概念和方法来解决需求，但是有一些专家已经做了这方面的尝试，如《分析模式》和《软件需求模式》。前者对需求模式的启发及后者对需求模式的总结都给SA带来的巨大的帮助。按照需求的问题域，我们可以把需求分为以下几个领域(From <Software Requirement Patterns>)：

Fundamental:所采用的技术，标准，内部子系统的边界及接口

Information:数据的结构，类型及生命周期

Data Entity:数据存储策略，包括事务、配置、数据实体

User Function:用户界面，报表，数据的获取和更改，可访问性

Performance:响应时间，吞吐量，动态容量，静态容量

Flexibility:可扩展性，可测量性，便携性，多元性

Access Control:认证与授权

Commercial:计费及税，可能涉及到多部门，多组织或者多货币

这是从另一个角度来对需求归类—概念角度。这种分类方式的好处是你可以从技术的角度来考虑如何来满足需求，迅速决定解决方案。它提供了很好的思考方式，将问题域的需求迅速分解，形成不同层次的几个小问题，大家都知道，10个小问题要比一个大问题容易解决得多。仔细想想，你所涉及的需求，很难逃出上面几个提到的领域。

实际上，各种方法论、技术、工具正在试图填平需求和设计之间的鸿沟，现实的情况是，最终还是要靠人来解决这些问题。关键问题又来了——寻找合适的人比什么都重要。回到技术本身，需求的获取与分析同样重要，如果你无法得到真实的、本质的需求，再高超的分析技巧也解决不了用户的根本问题，即便你真的可以解决用户提出的一些问题。另一个旁证就是一本书<The Toyota Way Fieldbook>上提到的，不了解问题的本质就开始解决问题，也许会解决一时的问题，但最终还是会回到起点。这样的例子太多了，尤其是在需求获取阶段，没能真正理解用户的需求，只是按用户的理解去实现系统功能，最终的结果常常无法令人满意，但没人愿意为此承担责任。我们都知道需求引起的变更所花费的成本会在后续阶段逐步放大，而且是呈数量级增长。所以需求的质量往往决定了产品/项目的成败。

因此，我希望跟大家多交流交流关于需求的获取和分析的心得。当然，我们的话题不仅限于此，可以涉及到软件开发的各个领域。