软件需求的关键：分解用例场景

做软件需求最重要就是分解用例场景，没有用例就不是需求。软件工程这类书要学，不过软件工程软件需求最关键就是用例场景的合理建立，这条，好象没有什么大学教科书谈到，仿佛中国的大学计算机科学系教师统统没有做过软件项目的，完全没有这个概念。所谓的软件需求，如果不是变成走不通的伪代码，就是用不上的美工方案，程序员对此除了干瞪眼是没辄的。

其中最大的原因就是从事网站或者类似的软件需求的许多人都不懂真正的软件需求是什么东西，包括我处理过的SAP/ERP项目这类都是同样的问题，尽管那不是网站；他们犯的一般共同的错误就是把网页表现形式（那其实是美工的工作），以及内容的采排看作是需求，完全没有一个用例的观念。

用例，usecase，目前多见于UML下的对面向对象程序中的对象行为的表达；不过，这不是它的源泉；它之所以被看作是这类语言的标准URL描述手段，是因为面向对象本身就是在虚拟程序中模拟真实世界那样地工作；而真实世界，就是围绕着用例展开的。用例的观念其实也不能算是一个软件概念，只不过在软件领域定义得最为精确而已，今天从每个人的生老病死，婚姻嫁娶，其实都是一个个的用例的描述和实施。用例，顾名思意，就是假如（假设）出现某种情况，采取什么样的行动；可能会有什么样的结果；然后，根据这个结果，再采取什么样的行动......直到得到希望的某个最终结局。

用例也叫场景，软件，实际上就是对场景操作过程的描述，而不是一堆版面框架网页的集成。没有用例支持就不叫软件，更加不叫项目——连垃圾都算不上。很多时侯我们说需求不明确，其实就是说这个用例不清晰；在电子商务网站中，除了人员素质导致对基本概念方法不明白外，最可能的导因就是商业模式不明确，或者不成立。这个成立与否，实际上可以从上面的假如如何那般的推导中进行初步的可行性推演。所以，程序员实际上有两个层次，一个是你说什么他做什么，但永远没有结果的。他却的确实现了你（需求人员）提出的所有要求，但这个项目却必然是永远没有结果的，因为，它本身只是把这个程序员当成网页编辑用了，项目没有基本用例的支持。我想90%的程序员是这类"程序员"，没有用例明确定义也就没有软件能力的评估，因为软件人员不是美工。另一种程序员则可以从上诉推演中发现整个项目本身有没有用例，以及用例是否合理（理论上没有明显的逻辑障碍）；虽然程序员一般不应该关心商业模式是否合理，但实际上他有这个能力，常常是第一个发现商业模式的问题，假如他也关心的话。

可惜大部分用户需求人员不明白这个道理，反而可能会以为程序员是在推卸责任，或者是刁难需求；也正因为这个原因，需求人员和实现人员的冲突在项目中屡见不鲜，倒不是个人矛盾的冲突，而是由于双方没能有一个基本的立足点。我见过这样的项目，需求人员建一个大型网站的需求就是一大箩的每个网页的非常详细的描述，到每个字每个连接......直至每个网页出现的次序，项目经理说一个笑话：万一他摔一跤，这箩子东西鬼才能再捡回原来的模样。的确，负责需求的客户方副老总和一帮企业需求编辑辛苦做了两个月，但其实这不是需求，而是使用这个项目软件的具体编辑排版的安排；根本不是程序员要看的东西。程序员需要的是使用这个网站时需要有那几种用例逻辑，然后抽象出其中的对象，根据对象建立存储方式（象数据库存储结构）和内容采摘方式。那大箩东东，实际上什么用处也没有的。开发软件如同建房子，旁观者可能问一句："建房子啊"就拍手说明白了，但对于开发员来说，如果得不到准确的房子细到砖砖瓦瓦的准确设计（需求定义）；要知道建小平房和建金茂大夏都是建房子，建宾馆还是建殡仪馆也是建房子，到底客户要的是什么房子合适，不搞清楚干下去的程序都是不负责任的，或者是冒牌货。

不懂软件需求的需求人员一般会犯如下错误：一是把版面美工形式看作需求，其实程序员看程序如同医生透过X光看一个人，看到的是骨架，至于是美人还是丑八怪如果能看出来，那个医生一定是变态的；在开发过程中都强调实现用例功能实现，而不是首先色彩如何花梢漂亮，后者不但不是主要的，也不是次要的，在开发过程中什么都不是；一开始把精力放在这里当成需求实现是浪费时间浪费金钱。二是把静态网页当成需求，特别是当把静态网页当成prototype时更经常犯这个错误；常常说："按prototype做出来不就行了？"实际上prototype本身如果不是看不出清楚的用例逻辑，就是可能有几种用例解释；何况真正变成动态程序，与静态的东西是不一样的。我在网上看到的美女明星下了台到眼前成了丑八怪，就是这个道理。而且更遭的是，客户还同时犯第一个错误，看着那里不顺眼就改一改版面还一天三变,不知不觉的基本用例就变成了另外一个东西，原来是宾馆现在成了盖殡仪馆，原来搞错了因为不知道躺的人不同叫不同的馆（死人还是活人），试问，如何实现？项目开始和后期看到的同一个版面成为不同的故事绝对是经常出现的故事，软件上称为需求变迁，这是项目经常延期的最主要原因。

三是需求人员把定制了解成按客户所有想法迎合静态页面，而不是按客户的业务用例要求建立相应的程序；还要求程序员也这样做；实际上，如果不能拨乱反正的话，任何项目到此为止已经是死路一条：那不是软件，无非是静态网页人员出租！需求人员常犯的另一个错误仍是不懂用例，就是把用例的使用方式当成了需求；这种错误有时连初级程序员都会犯，最典型就是把一个菜单栏目当成需求，而程序员无法从菜单中看出明显的简洁的用例逻辑——这是一个没有意义的菜单，天晓得里头是什么？同样地，里头的要干的东西还一天三变。事实上，同一种逻辑用例可以用到N个栏目，那是"软件的使用而不是软件本身"。

以上的错误常见于网站建设，所以网站建设最通常的结局是不了了之，大概占了50%以上，无论设入多少钱多少人花多少时间都是如此的；除非有人能够拨乱反正，让项目需求走上正道。而在ERP/DRP这类项目中，需求人员一般情况下是业务的行家，他们反而很容易理解用例是什么东西，象医院收费，绝对不会把精力放在收费界面有没有脱衣舞女让收费员提神上，收费这个用例有多少个环节是他们理解的。这种项目需求最易犯的错误是让先进的计算机工具重复原始状态下的不合理的流程。最典型的笑话就是：手工审批要盖五个章，用五天时间；现在电算化效率提高了一百倍，所以可以盖五百个章（电子签名呢！），时间嘛，仍然是五天！在这里，矛盾不是有没有用例，而是用例是不是合理的，最高效率的。

所以对于需求由于用例的冲突，程序员如果不想不了了之最后责任全部背上身的话，最好就是坚持原则；程序员迎合网页编写是没有意义的，迁就需求也不是没有意义的，因为......无法迁就的，越是迁就就越是没有办法实现，或者客户没有办法满意的。软件其实很简单的，无非是分析好用例，然后让计算机一步步实现而已，用例，是所有软件实现的前提：不然，软件到底要干什么？好的软件项目都有一个共同的特点，就是简单的逻辑，明确用例。最典型的，看google,ebay。