需求入门： 软件需求的三个层次

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

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

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

1. 业务需求
   

   　　描述组织或客户的高层次目标，通常问题定义本身就是业务需求。业务需求就是系统目标，它必须是业务导向、可度量、合理、可行的。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求从总体上描述了为什么要开发系统（why），组织希望达到什么目标。一般使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。组织愿景是一个组织对将使用的软件系统所要达成的目标的预期期望。比如“希望实施CRM后公司的客户满意度达到80％以上”就是一条组织愿景。这些最高级别的需求数量很少（2－5条）。
   　　以下为前景和范围文档主要提纲：
   
   　　RUP的业务建模流程（Business Modeling）就属于这个级别，有时我们也叫这些为事理。在这个流程中，业务流程分析员对企业目前的业务流程进行评估，根据要进行的项目得到一个业务前景（Business Vision），描述项目成功后会的样子，并在涉众范围内达成一致。业务需求层次需要投入的精力视具体项目而定，而业务需求的确定对之后的用户需求和功能需求起了限定作用，任何用户和功能需求都必须符合业务需求。
   
   

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

2. 用户需求
   　　用户需求是指描述用户使用产品必须要完成什么任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值，或用户要求系统必须能完成的任务，也就是说用户需求描述了用户能使用系统来做些什么（what），这个层次的需求是非常重要的。用例、用户故事、特性等都是表达用户需求的有效途径。
   　　户需求层次上的重心转移到如何收集用户的需求上，即确定角色和角色的用例，需求分析是很难的，因为很多需求是隐性的，很难获取，更难保证需求完整，而需求又是易变的。
3. 功能需求
   　　系统分析员描述开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（how），其数量往往比用户需求高一个数量级。这些需求记录在软件需求规格说明（Software Requirments Specification）中。 SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。
   　　产品特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
   
   　《Software Requirements》举了一个字处理程序的例子来说明需求的这三种不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。
   　　功能需求除了来自于用户需求，还来自于其它几方面需求：
   1. 系统需求（system requirement）
      用于描述包含多个子系统的产品(即系统)的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。
      
   2. 业务规则
      业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
   3. 质量属性（quality attribute）
      产品必须具备的属性或品质。系统的质量属性包括可用性、可修改、性能、安全性、可测试行、易用性和McCall体系等
   4. 约束（constraint）
      约束也称为限制条件、补充规约，通常是对解决方案的一些约束说明。
   
   这三个层次按照通俗一些的话来说，可以表示为下图：

　　在软件开发过程中，最为重要的“用户需求”往往和数量巨大的”功能需求“混淆在一起，这会让太多没有直接提供业务价值的需求充斥在需求阶段，这会导致没有突出重点而忽视重要的业务特性,这对业务分析来说是非常有害的。所以在开发过程中，很有必要加强认识并区分开来，有的开发平台（如普元）对这两类层次的需求就区分开来，如下图的构件种类对应关系：