深入了解了需求之后,成功的关键还在于“行”。俗话说得好“知易行难”,如何在实践中贯穿科学的理论,是彻底摆脱这一尴尬局面的重中之重。本文则通过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