需求分析的实践艺术

深入了解了需求之后，成功的关键还在于“行”。俗话说得好“知易行难”，如何在实践中贯穿科学的理论，是彻底摆脱这一尴尬局面的重中之重。本文则通过8个需求分析最佳实践的介绍来帮助读者更好地、因地制宜地驾驭需求这一匹习性难测的烈马。

1．实践艺术之一：利益共同体

在软件开发实现中存在的现实情况是客户介入太少，参与不足，而且对项目失败带来的后果估计不足。大部分客户都习惯于“委托”→“离开”→“验收”3段论，中间过程中的“离开”实际上是产生项目失败的一个很重要的诱因！

因此我们必须改变这种局面，通过“分析项目成功和失败对其的严重性”来使客户与我们形成“利益共同体”。

在这一实践中最有效的方法是隐喻，你可以通过容易引起共鸣的场景来打动客户，博得共识。例如，笔者在实践中，经常用“房屋装修工程”的隐喻来与客户沟通。因为用户都知道可以在房屋装修工程中，业主的时时关心、不断反馈是顺利完成工程的要因！这一点同样也在软件开发工程中得以印证。

2．实践艺术之二：共同目标

在功能分解盛行的今天，许多人常常会犯“盲人摸象”的错误。从而使得需求分析太过脆弱，难以经受考验。而要解决这一问题，请记住“目标！目标！还是目标！”这一警句。我们在软件系统开发中应采用目标驱动的思路，目标是团队惟一的行动纲领。

不过，还要注意的是，目标的定义不能够流于形式，应该具有的特征是业务、导向、可度量、合理及可行。要注意目标太夸大会浪费资源，目标太缩小会影响士气。

 教堂与小屋的故事

一位大臣走过建筑工地，看到两个工人在砌砖。“你在干什么？”他问一个垂头丧气的工人。

“我在砌砖”，第1个工人粗鲁地回答道。

“你呢？”他又问第2个吹着口哨的工人。

“我在建大教堂”，他高兴地回答道。

吹着口哨的工人的回答给这个大臣留下了深刻的印象。

（启发：宏伟的目标给吹着口哨的工人带来了工作的激情）

而当他再次走过这个工地时，却发现那个吹着口哨的工人不见了，而垂头丧气的那个工人还在。他就惊诧地问到：“你的同伴到哪里去了？”

“他被解雇了”。

“真糟糕！可以知道为什么吗？”

“他以为我们在建大教堂，其实我们不过是在盖一个车库罢了。”

（启发：错误的目标会使团队迷失方向）

那么目标在哪里？通常目标就是业务需求，因此是构建在“项目发起人”的脑子里的。即谁提出项目，谁就拥有对“业务需求”的最清晰的理解。在探究和概括目标时，应从宏观的角度来着手，并考虑以下问题：

① 思考企业运作中存在什么问题？

② 这些问题主要是体现在哪些方面？

③ 这些问题对企业造成了什么影响？

④ 认为可以如何解决？

⑤ 希望达到什么样的效果？

然后，将大任务分解成为小目标，并且引导客户良好地定义，这也是我们形成“项目子目标描述”的关键基础。另外还要注意一点，我们应该衡量这些目标的合理性与可行性。

而这项工作的结果应形成一个不超过50个字的项目目标，并且列出5~9个主要子目标，将其制作为一页文档作为“项目的行动纲领”。还应该得到“项目发起人”的认可，并在此基础上编写“项目的目标和范围文档”。对于产品而言，我们还可以构建一个从市场角度分析的“远景”文档。

3．实践艺术之三：框定问题

问题的定义是需求工作的第1步，也是最重要的一步。问题是否能够解决，通常与是否能够更准确地框定问题相关。例如，经典的马的遍历问题（寻找一系列的移动步骤，使马走完每个方块，而落入任何一个方块有且只有一次）表面看起来是一个十分复杂的非逻辑性问题，但如何框定得当，就会变得很具有逻辑性。图2-11所示将其转换为一个有已知算法的图的遍历问题。

因此软件需求第1个和可能最重要的步骤是框定问题。即把问题的特定部分，以及部分间特定的关系放入一个特定的形式中，问题框定方法应使问题的细节适合一个简单连贯的框架。同时也表现出深入地理解问题域的知识，正确地抓住其本质特性是十分重要的。通过将新问题转换到有已知算法的问题上，也将更有效地实现复用。

图2-11  马的遍历问题的转换

4．实践艺术之四：系统化地组织需求捕获

要进行需求捕获之前，最好对业务进行建模。常见的方法包括术语表、域建模和领域知识培训，而收集的信息可以采用Wiki这样的知识共享工具有机地共享。

对于与业务流程相关的系统，最重要的是置身于流程之中，分析信息和工作流。通常可以先索取客户方的“组织结构与岗位设置图”，对其管理层次与线条建立全局了解，这也是用例模型中“参与者”的来源。对于较复杂的业务流程，建议绘制出跨部门职能流程图，以帮助开发人员对客户方的业务流程建立宏观而清晰的认识，以便更加有的放矢地进行进一步的需求捕获工作。

在需求捕获开始之前，应该重点解决3个方面的问题。

（1）应该搜集什么信息

细化地研究流程图，看看是否已经清楚地认识了每个环节和每个步骤。我们应该根据自己的理解首先对每个流程的工作进行定义，写出事件流并且标识出疑问点，这些都将使我们明白“应该收集什么信息”。

（2）从哪里搜集这些信息

应从流程涉及到部门或岗位找信息，这点十分重要。

 闲聊惹的祸

在笔者参与过的一个项目中，曾经发生过这样的一个故事。在我们的需求调研人员进驻企业后，展开了一系列的用户访谈。

某天，按计划要与财务部经理进行访谈，结果那天他刚好很忙。这时企管部的人正好有空，不仅谈论了企划部的工作情况，还顺便把财务部的业务情况和需求进行了一番论述。

由于后来财务部的人一直较忙，需求调研人员就根据企管部人员的描述定义了需求。结果在系统开发完后，财务部经理则认为系统根本不符合实际情况，造成了大量的返工。

（3）用什么机制来搜集

需求捕获技术有多种，重点在于因地制宜地使用不同的机制。为了帮助读者更好地利用不同的需求捕获机制，我们对主要的技术进行横向比较。

 用户访谈——最基本、最常见的技术

利：直接有效、形式灵活且交流深入，应该作为主要的需求捕获技术。

弊：占用时间长（特别当客户忙时更显示出其不足）、面窄且易造成信息的片面性。

要点：一是要有准备，通常包括说明对流程的理解并征得客户的意见。预先根据流程中的不明确点设计要询问的问题，并将客户的反馈记录下来。应留有一些即兴发挥的空间，根据实际情况应变，以确保信息完善；二是要有计划性，计划好时间、人员及策略。

 用户调查——调查面最广的技术

利：面广，能够获得更多的人的反馈，是对用户访谈技术不足之处的最好补充。

弊：不够深入，容易形而上学，而这点是正是用户访谈技术所能够解决的。

要点：结合用户访谈技术使用，具体来说，首先设计问题，制作成为用户调查表。下发填写完后，进行仔细的分组、整理并分析，以获得基础信息。然后针对这个结果进行小范围的用户访谈，作为补充。

 现场观摩——最生动的技术

利：百闻不如一见，能够对需求与业务流程建立直观的认识。

弊：消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真。

适用性：要对于复杂流程的更加深入的理解时。

要点：悄悄地进行，明确要强化理解的具体流程环节。

 文档考古——最贴近实现的技术

利：能够详细并直观地对数据流细节进行了解与分析。

弊：易陷入文山书海之中不可自拔，甚至常引起误导。

要点：应该尽量让客户提供写有真实数据的文档。

 联合开发——最理想的技术

利：客户及开发人员直接的头脑风暴是击破需求盲点的关键手段。

弊：成本高，如果缺乏控制，则会变成一次闲扯大会。

要点：需要有一个经验丰富并能够把控大局的主持人。

5．实践艺术之五：基于用例对需求进行建模

用例分析的创建源于实践，Ivar Jacobson在爱立信公司研发AXE（电话交换机）时总结提出这个观点。用例的概念确定于1986年，所以它不应该作为一种新技术（有人认为是一个正处于临床实验阶段的新药）。许多人是在学习UML时接触到用例，并且产生了一些误解，误把用例图当做了用例分析的全部内容。用例分析技术已经广泛地应用于许多软件开发组织的实践，收效甚佳，成为了软件需求最佳实践之一。用例分析技术与AOP的结合，使其优势能够继续在设计与实现阶段得以贯彻。

需求建模的工作应该在“业务需求”充分理解，并且收集最本质的“用户需求”之后开始需求分析，但并不是等到需求捕获完全做完之后。而且应该采用的是交替进行的方式，首先把握住用户需求的主要部分，然后开始分析。在分析的基础上引入系统级的需求（即从系统的设计与实现角度进行考虑），并且根据分析的结果建立分析模型。这个模型将成为伴随整个需求过程的关键内容，并且成为开发人员之间、开发人员与客户之间达成共识的一个平台。

要注意的是需求分析与建模不应该是孤立的行为，它应该汇集项目团队成员的智慧，在开放且融洽的气氛下协作完成。而且其产生的结果也不一定必须是规范度很高的标准文档，而应该重在分析、方法、交流并解决问题。在笔者的实践中发现，团队聚在一起利用白板，甚至是纸张，在充分的合作下进行分析与初步建模是成本最低、效率最高且实用性最强的方法。对于这些活动所产生的结果，可以利用数码相机或扫描仪进行文档化，并置入共享及版本控制，重要的再用CASE工具进行电子化。

6．实践艺术之六：利用需求基线来控制节奏

在每次或每几次迭代中，建立一个刚性的需求基线。在开发完成之前，开发组（注意是开发组）不响应变更。而是一门心思考虑如何完成基线中的需求，以保持良好的开发节奏。

如何构建这个基线？我们应该在分析的基础上将需求整合成为用例或功能项，并对其优先级、依赖性进行综合性评估。然后将一部分优先级高的需求放入迭代的目标，周而复始，直到所有的需求都已经被实现为止。

7．实践艺术之七：持续进行需求跟踪

要想能够正确地评估变更的影响面，以及其所带来的工作量变化，很重要的是对需求进行跟踪管理。

要建立一张映射表，将需求项与分析项、设计项和实现项建立清晰完整的对应关系，以便一目了然地获得所需的信息。

这项工作可以借助RequirsitePro或Door来解决，也可通过Excel创建对应表格，其关键还在于经验的积累。

8．实践艺术之八：为需求工作建立合适的过程

合适的过程是高效团队的黏合剂，因此要想提高需求管理的质量，必须建立合适的过程。软件过程的描述应该包括图2-12中所示的内容。

图2-12  过程规范结构示意

不过，要注意的是只有“印在开发团队成员脑海中”的过程规范才是有效的过程规范，仅写在文档上的过程规范只是一纸空文。因此一开始可以尽可能地简单，让团队适应后根据实际情况修改、增加，并不断地进行改进。如同红军当年以“三大纪律，八项注意”打造了一支军纪严明的仁义之师一样。

 

转自：http://blog.dev.kingdee.com/pages/sjzxyt/blog/archive/2007/08/25/233243.aspx