谈谈需求（上）

         楔子

标题叫《谈谈需求》其实不好，因为需求只是一个名词，但是很明显我这所指并不是要阐述“需求”这个概念，而是指需求分析这个阶段性动作。但是后续可能还会写谈谈设计、谈谈测试、谈谈写代码之类的文章，做成一个系列，为了标题对仗，也就把动词省略了。

何谓需求，往小了说，就是用户想要实现的一个IT系统功能；往大了说，其实也是人类求生欲望的延续，就类比克劳.塞维茨说的——战争不过是政治的延续。当然，这里的求生在人类科技文明高度发展的今天，不仅仅是求生存，而是求生活——渴求更好的生活。这种生活不仅仅是满足人的物质生活，更是为了满足人的精神生活，以求精神富足。

         将IT技术拿出来看，其实不过是人类更高效工作、更方便生活的工具与手段，用户需求，本质上不过是人们高效工作或更好生活的欲望的可实现性延续，是为了满足人的信息生活而存在。这里所谓“可实现性延续”，一不小心又说成了一个IT术语，即是可以在软件系统中实现的功能延续。

         概念辨析

说到“需求分析”，很容易让人联想到《需求分析报告》，但是我这所指并不仅仅是这一步，还包括《需求规格》。这两份文档是需求分析阶段中用户需求分析、功能需求规整这两个前后相承的分析设计步骤的阶段成果性交付文档，而生产出这两份文档的这两个步骤亦是整个需求分析阶段的两大关键步骤，这两个步骤的质量高低很大程度上决定了未来实现所的系统的功能稳定程度、与用户需求期望的匹配程度，也是软件系统架构是否稳定的一大决定性的影响因素。

         说到《需求分析报告》、《需求规格说明书》，很多人总以为这就是一份文档，或者分不清这两者的区别，其实很简单，各自加上两个字就一目了然了——《用户需求分析报告》、《功能需求规格说明书》。

         《需求分析报告》是需求分析师收集了用户需求进行系统分析后所形成的最终结论性文档，而《需求规格说明书》则是软件设计师根据《分析报告》中所分析出的分散的功能需求，进行系统级的统一规整的产物，也就是说“需求分析”分析的是用户需求，而“需求规格”规整的则是功能需求。《需求分析报告》是《需求规格说明书》的输入，《需求规格说明书》是《需求分析报告》的最终输出。两者的描述内容可能相近，但并不等价，各有侧重。用户需求侧重从用户角度出发来描述一个需求，相对而言，比较抽象化、感性化；而功能需求侧重从产品定位、系统设计与实现的高度来考虑一个需求（对，是高度，不仅仅是角度），因此会更加系统化、理性化地来考虑需求的实现，若能配上界面原型图，就能更加具体、接地气。

         史蒂夫.乔布斯说过“用户永远不知道他们自己真正想要的是什么。”，此话同样适用于软件工程领域的需求分析工作，因为用户对IT知识的掌握程度有限，所以并不能苛求他们能用很专业的IT术语来将一个业务需求描述得很清楚。他们对需求的描述往往会更贴近于他们的具体业务背景，甚至会夹带很多所在业务领域的专业术语。他们口中所说的需求也许并不是真正的功能需求，而只是他们业务中真正需求的一个“外体化、形象化”的展现。用户口中所说要实现的“功能”也许并不是真正能满足他业务需求的功能，只是由于他的IT知识所限，只能描述成这样。

         所以需求分析工作一定要系统、客观、冷静。需求分析人员应该尽可能地引导用户将他们心中真实的需求“吐”出来。为了达到此目的，需求分析人员甚至可能还需要对目标用户所在业务领域进行一定深度的了解，以便尽可能地熟悉用户关注的业务场景，通过业务场景的熟识，来了解用户真正的业务诉求。

需求分析报告内容组织

         到此，本文总算可以进入正题了，也就是《需求分析报告》具体要做哪些工作、内容如何整理输出。根据上文思考，需求分析报告必然以业务场景为单位进行整理，当业务场景数量开始庞大时，就需要将业务场景进行分类，而分类的标准，根据笔者的经验，倾向于根据需求来源划分（每处来源用一个一级标题标识），而不是根据预先设计的系统大功能模块来划分。这样做的好处就是便于不同业务用户进行需求跟踪、以及最终的需求签署确认。业务用户只需要关注自己那个一级标题下的需求的分析过程就可以了，而不需要从全篇文档来Search属于自己的需求。

         说完了业务需求的整理规范，接下来该讨论《需求分析报告》的核心部分——内容组织了。需求分析报告一般都包括以下几部分，也即是可以作为一级标题的内容：产品目标与范围、用户需求（包括原始需求清单、用户需求分析、安全性需求、质量属性需求）、约束条件、术语约定。

产品目标与范围

简短描述该软件产品的开发目的，包括功能利益和产品定位目标等，把软件产品开发与企业目标或者业务策略相联系，一般包括产品目标描述与业务范围界定两部分。前者需要明确此项目的业务期望目标、产品定位；后者需要能明确此系统的用户范围、功能范围、甚至地域范围。

业务功能性需求

用户需求部分是此文档的核心部分，首先包括一个用于统计跟踪原始需求用的用户需求清单，该清单维护的目的即是方便业务方跟踪总揽所有原始需求，一般以表格形式记录，包括业务需求编号、需求来源、原始需求简短描述等内容。

对业务需求有了总体记录后，接下来便是详细的业务需求分析了，这也是需求分析报告交付质量高低的核心内容。此部分内容中，需要对每个业务需求进行细致系统分析，因此一般以表格形式表述为好。每个业务需求对应一个小表格，主要包括以下几个部分内容，每行描述一条：需求编号、业务需求描述、业务处理流程、用户范围、前置条件、业务规则、关键功能需求点、需求提出人。最好是以表格形式来描述。

         需求编号：这是用来检索所有业务需求用的，一般是如下格式：R.BussinessDomain2.008，R是《需求分析文档》字母简写、BussinessDomain2用于标记来源，008则是需求顺序编号。如果对word文档操作很熟练，此处编号建议自定义一个自增式编号格式，这样方便后续插入业务需求时文档自动编号。

         业务需求描述：以文字形式来记录业务提出的原始需求语言，尽可能细致明确但不罗嗦，多用短句对业务点进行明晰表述。

         业务处理流程：在业务需求描述基础上，对业务期望的处理流程进行描绘，尽量抽取出重要流程节点，建议用类似流程图的格式描述。

         用户范围：在需求分析阶段，参与者不需要马上分别出系统角色，可以按照实际业务角色来记录即可。

         前置条件：描述执行此业务功能的前提条件，有可能由此产生与其他系统集成的接口需求。

         业务规则：用于描述执行此业务功能的业务约束性条件，包括逻辑判定、数据边界值等，例如，一个数据输入，数据最大、最小值是多少。。

         主要功能需求点：此处是业务需求分析的主要交付成果，需求分析人员根据上面的“业务需求描述”内容，并参考“业务处理流程”，初步抽取出核心功能需求点，此处需求点尽量以列表展示，句式简洁扼要但必须语意清晰，尽可能挖潜出用户尚未表达出的真实需求。对于需要集成业务需求的软件系统，此处可能会产生与外部软件集成的接口需求，此接口需求将对应《需求规格》中的外部系统集成需求部分内容。

         需求提出人：此处记录此业务需求的提出人，也是业务需求确认人，若后续需求蔓延，或者因开发技术性原因导致需求无法全部实现，均跟此人沟通确认。

需求编号 业务需求描述 业务处理流程 用户范围 主要功能需求点 业务规则 需求提出人 

         非功能性需求

         非功能性需求包括可用性需求、可靠性需求、可扩展性需求、性能需求、安全需求等内容。某些文档中还包括硬件需求等。

         这些内容大多跟具体业务相关，本系列文章着重软件系统设计，在此就不过多细述了。

        

         费了这么多口舌，堪堪写完需求分析，需求规整还没开始，那就未完待续咯。不过行家应该知道的，《需求规格说明书》核心就是Use Case。

 

         散论

用户需求实现的最终目的并不在于为讨部分用户欢心而去花大力气实现某个好看花哨但不实用的功能，而在于通过此系统更好的满足绝大部分用户的业务需要，提高其业务执行效率。注意，我这讲的是“此系统”而不是“此功能”，因为功能永远是局部的，而系统则是整体的。局部功能强大所致的局部工作效率提升并不一定就能代表整个事务效率的提升。只有开发系统的帮助事务在各个重要节点都得到普遍效率提升，才算是真正地满足了用户需求，达到了业务期望。

 

一个一直坚持的观点：其实，软件工程文档的模板并不仅仅是模板，而且并非各自独立的文档，而是一整套相互联系的设计说明书，是系统开发思路的节奏性体现，就像剥洋葱，层层剥开，循序渐进，每一个步骤都马虎不得，这类设计文档写到一定程度，设计人员就能根据当前阶段文档撰写的流畅程度去判断前一阶段文档交付质量的好坏。因此，可以这么说，这一套文档模板水平的高度就直接决定了软件设计水平的高低。

 

         写这些文章的用意，其实很简单，技术之路漫漫兮，望乞高人指点一二，望与同仁切磋切磋，以不至于把路走偏走绝。