猿设计4——隐藏需求及实体的挖掘办法

看过上一章节相信你从感官上对电商的前台系统和后台系统有了一个感性的认知，也学些了UML用例图的基本画法。也开始学会如何从功能点中去寻找实体。也许你会觉得我们寻找出来的实体，相对简单，而且寻找的功能点也不够完备，用这些功能点和实体，很难串联起来实现一套完整的系统，今天，我们将学习一个新的法门——系统的隐藏实体和隐藏功能的识别与搜寻。

昨天我们通过对比UML用例图的方式，挖掘出了系统的部分实体，我们可以先看一下。

这些实体看上去粒度粗矿了一些，一眼望去也没有什么关联，很难想象怎靠这些东西来运行一套系统。今天我们对这些实体进行再一次的分析，挖掘系统中隐藏的实体和功能点。

这些隐藏的实体和功能点，往往就是容易埋坑的地方，正所谓需求一行代码万行，拿着功能就动手，不前前后后想清楚，心直口快就应承下需求，几乎是小猿猿们的通病，所以这部分知识也好好看看，如何通过已有的一鳞半爪去挖掘隐藏的东西。

好了，废话不多说了，买东西和卖东西自然离不开对东西进行分门别类了，我们已经能够看到类目了。就问一句，类目的数据从哪里来？界面上没有提到啊？别忘了，马老板的东西是给卖家用的，它肯定还是有一套数据的，只是给了卖家使用而已，我们自己玩耍个B2C，总得有数据维护的功能吧。好了，发现隐藏功能一套，UML画一下吧。

同样的道理，品牌的数据从哪里来的？总不能从天上掉下来吧？作为系统层面的考虑，你还是需要维护起来的。所以又发现一个功能点——品牌数据维护。

再看看类目属性、商品属性，道理同样如此，作为系统层面，都得提供出来，要不系统是没有基础数据的。

我们再看看用户地址这一块儿，地球人都知道，前台购物的时候选择，省市、区，这个是最早的时候了，电商发展到今天，已经有了第四级地区的概念，比如，四川省成都市高新区下还可以选择，比如大源，石羊场，中和场，桂溪街道，而这个四级地址是国家地址库没有的，属于后续业务发展，相关的从业人员维护出来的，我们还是需要维护起来的。

地区这个概念，之间是有联系的，比如省下面是地级市，地级市下是区或者县，是一种典型的父子关系，在过去的设计中，往往通过层级来体现这个概念，但是现在业务发展之后，大家对地址这个概念越来越重视，尤其是四级地址(各自维护了一套数据来源于配送的采集，极为有价值)，所以在设计上也加细致,这里算是隐藏了一个比较深的功能误区，省（一级）、市（二级）、区（三级）、四级地址都需要单独维护了。

我们再看看承运商信息，承运商信息和发货的功能是息息相关的，发货这个事情是需要选择承运商的，作为系统层面，还是需要一个维护功能，提供承运商信息用于选择，所以我们又找到一个隐藏的系统功能点了。

我们再看看评论这个功能，关于这个功能有一个段子，某宝做的是评价体系，也为此投入了大量的人力物力，某个大嘴曾经说过，解决好评问题很简单，只需要请一个程序员就阔以了。所以，作为B2C嘛，这一块儿可以简单一些，附带的功能也是奖励性质挂钩的——一般是奖励虚拟资产，这一块儿我们可以先简单的画一画。评论还是要注意一些事情的，如果尺度比较大，机构是要吃瓜的，比较有意思噢。

你以为这一切就结束了？如果真的这样认为的话，你就真的又犯错了。用户不需要管理吗？说好的活动信息呢？促销信息呢？优惠券信息呢？这些信息都由谁去维护？最基础的东西，往往是最容易忘记的事情。所以在进行系统分析和设计的时候，不要觉得枯燥无聊，除了要对隐藏的功能要进行挖掘，还要打起精神，多回顾一下之前的设计，看一看有没有遗漏的地方。