OOA&D实践之路——真实案例解析OO理论与实践（二、第一项任务：特性列表）

查看本系列全部文章：
《OOA&D实践之路——真实案例解析OO理论与实践》索引贴

第一份说明
      当这个项目开始时，我们得到的关于我们要做的系统的唯一说明是一页Word文档，这是一份简单的不能再简单的说明。文档里只有一行字：我们需要一个系统，使得全国各地的代理加盟商和连锁店能够通过网络订购原料。另外，我们还知道这是一个食品公司，主营面包、麻花、肉夹馍等食品，在全国各地有多家连锁机构。除此之外，我们一无所知。

永远不要和客户谈需求
      软件开发的第一步是什么？很多人觉得是需求分析。显然这短短的一句说明无法满足我们的要求，于是很自然的，你希望找客户谈话，详细了解情况，然后做出详细的需求分析。于是，你心里有了这么一个算盘：

      和客户谈话 -> 问清所有需求 -> 进行需求分析 -> 生成需求文档

      乍看之下，这是很合理的步骤，但是实际上这是不可行的。原因有如下几点。
      1.客户不关心系统的所有方面
      每个开发人员都希望，客户可以清楚的把自己需要的东西的方方面面清楚无误告诉你，然而，这只是一厢情愿罢了。因为，任何一个客户在需要什么东西的时候，只会大致想想要个什么东西，并不会将所有地方都仔细想清楚。
      2.有时客户并不清楚自己到底要什么东西
      有时候，客户并不是很清楚自己想要什么。这不是天方夜谭。很多时候，客户仅仅有一个“想要实现某个目的的动机”，而没有“我需要一个什么系统”这么明确的概念。例如，从上文那个“一句话说明”中，可以看出，我们的客户仅仅是有一个动机：希望有一个系统，能使得他们公司的代理商和加盟店在线定料，至于这是一个什么样的系统，他们并没有明确的概念，更不用说这个系统有什么样具体的需求了。

      基于以上两点，你是不可能从客户那里问清所有需求的。实际上，就不该和客户谈需求，因为需求从来就不是“客户面”的东西，而是“开发人员面”的东西。需求需要包含方方面面系统需要实现的功能，而客户往往并没有如此精细想过，甚至客户自己对自己想要的东西什么样子都不清晰。面对这种客户，你一本正经往他面前一坐，开发笔记本说：“我们谈谈需求吧”，或说“我们进行需求分析吧”，我想客户会立马崩溃，而你也不可能得到你想要的所有东西。
      作为开发人员，不应该一开始就和客户谈需求，而要先谈特性。很多需求并不需要客户告诉你，开发人员应该能通过常识识别出来，就如没有哪一个买汽车的客户会说：我需要一个辆汽车，要有方向盘，还要有四个轮子。他们通常会说：“我要一辆家用车、要省油、舒适，要至少能坐3个人。”这“家用车”、“至少能坐三个人”就是特性。
      特性是一些描述，一条特性简要描述了系统的一个客户最关心的核心功能。
      最为开发人员，首要任务不是做需求分析，而是帮助用户整理出一份特性列表。这里之所以说“帮助”，是因为很多时候，客户由于自身太关注于某个方面，而漏掉了十分重要的特性，这是你要帮客户想想，并将想到的特性询问客户是否是需要的。如果客户很高兴的说“对！对！”，那么这就是大功一件。所以，在初期阶段，开发人员一定要想客户之所想，急客户之所急，尽快帮客户理清系统有什么特性。
      所以，正确的过程应该是：

      询问客户系统都有什么功能 -> 写出初期特性列表 -> 想想什么遗漏特性，并询问客户 -> 查漏补缺

生成特性列表
      下面回到案例。
      虽然客户的说明只有一句话，我们还是整理出一份初期的特性列表，并将其作为我们向客户展示的第一份工作成果。这份特性列表内容如下：

      1.可以将各种原料信息发布到系统上
      2.加盟商和连锁店可以通过系统在线定料

      没错，我们的初期文档只有两项特性。我们把这个给客户看，客户说：“嗯……大约是这个东西吧。”很显然，我们的客户是比较懒的那种，这时，我们有义务引导客户想起更多需要的特性。下面是当时大约对话：

      开发人员（简称D），客户（简称C）
      D：你这个加盟商和连锁店是要如何区分呢？
      C：我们公司有一个加盟商和连锁店的记录。
      D：那么你们是准备将各个加盟商的信息全部录入系统吗？
      C：不是，我希望他们能自己注册，就和论坛那种。
      D：那么你要如何确认他们的身份，总不能任何人都可以在这个系统注册吧。
      C：嗯，我们公司有各个加盟商的详细信息，我们希望他们注册时提供足够的信息，我们进行核对。
      （于是我们飞快写下一个特性：加盟商和连锁店通过网络进行注册，总店负责人审核后才可以正式使用系统。）
      D：你们得在后台能发布各种原料的信息吧。
      C：嗯，使得。
      D：这里有没有什么特别的要求。
      C：没有吧……
      D：好的，那么你们准备设立几个人负责管理这个系统。
      C：就一个人吧，就信息部那个。我们就这一个比较懂计算机的。
      D：也就是说不需要有多个人分别管理这个系统？
      C：不需要。
      （写下一个特性：系统需要一个管理员，可以对系统进行管理）
      D：在你们的加盟商进行定料时，你希望他们怎么操作啊。
      C：这个，我没仔细想过……
      （看客户对这个地方比较不清晰，我们打开了一个网上书店的网站，给他演示了一下购物车购物的过程）
      D：你看，你的这个定料过程是不是和这个购物过程很相似，加盟商定料是不是就相当于从总公司购买原料啊。
      C：对对！就要这种效果的！
      （这里要记住，在特性不能直接说清楚时，找相似事物是一个不错的选择。也就是说，说明这个特性像什么，不像什么）
      （我们又加一条特性：使用购物车功能进行网上定料）
      D：付钱这一块怎么弄，需要网上支付吗？
      C：不了，我们一般又财务专门做钱这一块工作。
      D：那买完原料后要不要什么凭证呢？
      C：买完后生成一份定料单吧，打印出来，交给财务，财务清算款项，款到账后通知原料那边发货。
      （又一条特性：定料完成后生成定料单，并可以打印）
      D：那么关于这些交易，你一定希望能查询吧，你希望怎么查询。
      C：哦，这些我们财务那边有专门的财务软件。你这个系统只要能让加盟商定料就行了。

      到这里谈话基本结束，我们得到如下一张补充过的特性列表：

      1.可以将各种原料信息发布到系统上
      2.加盟商和连锁店可以通过系统在线定料
      3.加盟商和连锁店通过网络进行注册，总店负责人审核后才可以正式使用系统
      4.系统需要一个管理员，可以对系统进行管理
      5.使用购物车功能进行网上定料
      6.定料完成后生成定料单，并可以打印

      我们将补充后的特性列表给客户看了看，基本得到了认可。
      到了这里，我们第一步就差不多做完了。但是，我们还是不能马上进入需求分析，因为这之前还有很多事情要做。例如，特性整理，风险规避，这都是后面要讨论的话题。

重点总结
      1.客户不会想到方方面面。
      2.有时客户并不明确自己想要什么东西，而仅仅是有个动机。
      3.不要和客户谈需求，要谈特性。
      4.开发人员有义务引导和帮助客户挖掘系统的特性。
      5.当客户描述不清某个特性时，可以采用找类似事物的方法，说说这个特性像什么，不像什么。
      6.在软件开发初期，我们需要首先整理出一张特性列表，而不是做需求分析。

作者：T2噬菌体
出处：http://leoo2sk.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。Tag标签: 面向对象,OOposted @ 2008-12-08 21:56 EricZhang(T2噬菌体) 阅读(2221) 评论(25)  编辑 收藏 网摘 所属分类: 面向对象技术
发表评论  回复  引用  查看     #1楼 2008-12-08 22:15 | 简简单单       沙发！支持！
  回复  引用  查看     #2楼 2008-12-08 22:35 | GUO Xingwang       文章写的很好，支持楼主坚持写完这个系列！
  回复  引用     #3楼 2008-12-08 22:37 | zjpixy [未注册用户] 很好。。。希望能坚持。。
  回复  引用  查看     #4楼 2008-12-08 23:09 | yonbin       不错！支持!!!!!!!!!!
  回复  引用  查看     #5楼 2008-12-09 01:20 | 牛牛x       顶一个，说的很实在！
  回复  引用  查看     #6楼 2008-12-09 01:25 | Astral.Road       需求还是专人或者擅长的去做, 经常埋头写东西的人跟客户去折腾经常会抓狂的 ^_^
  回复  引用  查看     #7楼 2008-12-09 01:50 | 上不了岸的鱼{ttzhang}       呵呵，我又来掺和一下
  回复  引用  查看     #8楼 2008-12-09 08:54 | 球球       一直在考虑如果让UI设计师兼职需求会怎么样，用户大多数还是可以说出，我想这里有个按钮，一按就能出来什么什么东西之类的，一边考虑UI，一边整理需求也许是个不错的选择。
  回复  引用  查看     #9楼 2008-12-09 09:07 | sober       很好～开始看到说不进行需求分析的时候有觉得这篇文章应该写得不错
  回复  引用  查看     #10楼 2008-12-09 09:14 | airwolf2026       小小的关注下.
  回复  引用  查看     #11楼 2008-12-09 09:31 | relax       了解需求是很难的事情……我在实际工作中也遇到过一句话的文档。

楼主的思路很清晰，和客户讨论也很真实。

但对于一些行业软件可能不是这么简单能理清思路的了。

有时候客户说的专业名词我们可能都不能理解

记得我刚刚接触财务部门的用户的时候就不理解什么是"授信"；
  回复  引用  查看     #12楼 [楼主]2008-12-09 09:54 | T2噬菌体       @relax
行业业务和专有名词确实是很令人头疼的问题
  回复  引用  查看     #13楼 2008-12-09 09:54 | 毁于随       不错,这里是不是就可以配合用例了?下面才是真面的需求分析吗?这篇只是确定特性,从而确定了系统的边界?
  回复  引用  查看     #14楼 2008-12-09 09:57 | 毁于随       @relax
对对,文章中一直是D来给用户启示来寻找需求,似乎D成了领域专家,而事实上C才是领域专家,D的理解有的时候是错误的,当然错误也可以拿出来讨论,由C来讲解.所以,一般来讲,我认为楼主缺了一个环节或者是第一个环节做的还不够,我认为应该是让C来讲一下他所设想的大致流程,讲讲相关的领域知识,然后D再来梳理特性,再来发问,这样更便于沟通.
  回复  引用  查看     #15楼 [楼主]2008-12-09 10:43 | T2噬菌体       @毁于随
事实上，当时我们是让他讲一遍流程，但是客户只有那一句话。所以只好我们通过常识引导一下他了。但是你说的是很对的，对于很多复杂的业务，应该先由客户讲一下大致流程和领域知识，以便更好沟通。
  回复  引用  查看     #16楼 [楼主]2008-12-09 10:44 | T2噬菌体       @毁于随
这里还不能使用用例。用例很容易将人引入细节，我们首先要有一个全局观，不能过早陷入细节。
  回复  引用  查看     #17楼 2008-12-09 13:07 | 墙外行人       什么是需求？什么是特性？特性是不是需求呢？为什么？
我一直把特性当做需求
  回复  引用  查看     #18楼 2008-12-09 17:08 | Done       的确不错,写到后面希望把代码粘一粘,很好的东西啊
  回复  引用     #19楼 2008-12-09 17:16 | Hand [未注册用户] 好文章，继续关注
  回复  引用  查看     #20楼 2008-12-11 13:38 | 金色海洋（jyk）       我一直把lz说的这些都当作了“需求分析”了，原来不是呀。
  回复  引用  查看     #21楼 2008-12-11 13:41 | 金色海洋（jyk）       楼主的意思就是要用“询问”的方式，来获取客户的所有的信息。
  回复  引用  查看     #22楼 2008-12-13 15:43 | 刘晓飞       和客户谈话 -> 问清所有需求 -> 进行需求分析 -> 生成需求文档。这个流程没有错至于你说的“询问客户系统都有什么功能 -> 写出初期特性列表 -> 想想什么遗漏特性，并询问客户 -> 查漏补缺”只不过是对“问清所有需求”的一种详细说明罢了，是开发人员收集需求信息的一个过程。 你说的“特性”我认为就是开发人员和客户交流所取得的需求信息。
  回复  引用  查看     #23楼 [楼主]2008-12-13 17:15 | T2噬菌体       @刘晓飞
呃……个人认为没有必要抠这个字眼。我这里要表达的主要意思就是“不要期望客户告诉你全部需求”和“开发人员有义务提醒客户”，只要抓住这个本质，字面不重要。
  回复  引用     #24楼 2008-12-29 00:44 | 胖达 [未注册用户] 没事闲的，浪费文字，拾人牙慧了
  回复  引用     #25楼 2009-05-08 14:29 | Francis [未注册用户] 所有过程之前加上——理论或行业调研。只有这样沟通起来才更高效。