由用户操作手册开始的需求分析设计

今天的主要工作总结为编写了代理商操作手册，明析了需求，从需求中抽取出表和对象，这些事情我怎么做的呢？我在这里说一下。

 

我现在正在着手做一个代理商分销系统的开发，这个系统我跟销售人员和业务经理沟通出了一些大致的需求，并进行了简单的归类，以领域驱动设计（DDD）法来进行了简单的设计后发现我对这个需求的理解还是很抽象，要想将它制造出来还需要了解很多细节的东西，然而我要如何才能清楚我所需要的每一个环节呢？如何才能保证我不会被遗漏一些代理商的操作细节呢？

 

我在这里用我学到的“软件之始于用户操作手册得到的需求分析”，我换一角色，将自己作为一个代理商的角色，然后参考了一些资料，来模拟一个代理商如何使用一个系统来与公司总部进行信息的交流和共享。

 

我这里使用了两个角色，代理商和采购中心，信息的发送方式我认为从最简单的开始，代理商发送信息到采购中心，然后采购中心处理这些信息，然后回馈给代理商。

 

在这个过程中我觉得有一个转换层，将代理商的信息交给采购总部的时候将会被采购中心的人员进行一次转换，将原始的信息转换为可以从采购中心发送到其它地方的信息。然后其它信息再回馈回来，采购中心再将信息转换一下，回馈给代理商，这就是我最初的想法。

 

我写了一份大约七页的用户操作流程手册，命名为代理商平台结构指南，我将这份流程通过EMAIL的形式寄送给公司经理和业务经理，希望能和他们进行论讨，一切失误和不足在这一步进行修改和完善的成本应该是最低的，所以尽可能的在这个层面的时候就完成骨架，在接下来的日子就会好过很多了。

 

但是并不象我想象中那么顺利，我的邮件几天都没有被人处理，于是我只能自己完善这份文档，我在分析我的抽象需求的时候发现我遗漏了一样东西，那是分销公司现有产品的一个流程，我马上把这个流程加入到整流程中去，然后又对以前的流程进行了一些调整，到现为止，我对合同的流程还不太清楚，我希望在接下来的时候了解到更多流程。

 

后来我又发现，其实我把一个问题想的过于复杂了，我原来可以对现有的数据结构进行扩展来适应这些变化，只是这样子就增加了编码的复杂度，而减少了数据库的复杂库，这两个总是无法平衡的。越简单的数据库设计程序编码就会相对复杂一些，而数据库设计的复杂了，程序结构就会相对简单很多。我认为是这样儿。

 

我在这里一直说流程，因为我认为在系统构建之初，流程应该不能出差错，流程是可以变的，但是必须要有变化点，没有任何地方都能变的设计，就算有，那一定也是个很糟糕的设计，而现在，在这里由我设计和进行编码最后测试通过，所以我可以假定最初我预定的那些流程和数据结构是正确的，既便是有改动，也可以通过增量的方式进行完善。

 

 

我开始了构建最初设计的原型，对于我不了解的一些流程和功能还有数据结构我保留空白。

 

现在的我一直强调自己编码，尽量用较短的时间来设计，因为我发现自己经常陷入设计泥谭。我现在使用的模式是文档，编码，再修改文档，再完善编码，这样子不断的迭带，我不知道其它人是怎么开发软件的，我很想了解，向他们学习一些可以提高开发效率的方法。

 

今天就写到这里，明天计划是把预定的这些功能都实现