作为技术人员，我们以往更多的关注的是技术，但是在做个多年后，发现做正确的事比正确的做事更重要，而软件中需求的好坏很大程度决定了你这个 软件是否正确，需求确定后不管你如何实现，功能给客户直接带来的价值远远比技术直接带来的价值要高。鉴于需求的重要性，所以后续我将陆续写一些需求相关的博文和大家一起学习探讨，扩充开发人员的需求知识，提高我们应用需求到开发的技能。

　　本篇将从下图所示的软件需求的三个层次开始我们的需求之旅。

　　上图为需求的层次关系图，软件需求包括三个不同的层次：

　　1、业务需求

　　描述组织或客户的高层次目标，通常问题定义本身是业务需求。业务需求是系统目标，它必须是业务导向、可度量、合理、可行的。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求从总体上描述了为什么要开发系统（why），组织希望达到什么目标。一般使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。组织愿景是一个组织对将使用的软件系统所要达成的目标的预期期望。比如“希望实施CRM后公司的客户满意度达到80％以上”是一条组织愿景。这些高级别的需求数量很少（2－5条）。

　　以下为前景和范围文档主要提纲：

　　RUP的业务建模流程（Business Modeling）属于这个级别，有时我们也叫这些为事理。在这个流程中，业务流程分析员对企业目前的业务流程进行评估，根据要进行的项目得到一个业务前景（Business Vision），描述项目成功后会的样子，并在涉众范围内达成一致。业务需求层次需要投入的精力视具体项目而定，而业务需求的确定对之后的用户需求和功能需求起了限定作用，任何用户和功能需求都必须符合业务需求。

　　大家可以使用免费的Sam业务流程梳理建模工具软件来进行业务梳理，坦白说我也没有实际真正的使用过这个工具，推荐它是因为它里面提出了用企业价值增值链图(EVC)和企业事件过程链图(EPC)来进行梳理，可能有人说这个工具不如Visio好用，想怎么画怎么画，其实业务建模重在内容，并且图标需要统一规定。