·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

        ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

        ·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
这几项都有包括啊，回头问问差在哪里了。
  虽然大赛并没有要求提供需求分析文档，但是需求在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用，所以，就像软件工程的流程一样，一切从需求开始，一切文档化。
         接着修改。。。。。。。

            
这里有一个很好的关于SOA的过去，现在，将来的比喻。
SOA------〉城市的发展
初期：一个小村落，两个小村落，一些小村落
现在：城市，要规划哪些是商业区，哪些是政府，哪些是居民区等等，要有一个全局的规划
将来：虚拟的社区，在家里即可购物，等等。即虚拟化，动态的划分。
未完，待续。。。。。

　　开始简单的SOA使我们可以在作出大的决定前之前先衡量，并在出现大的问题之前获得小改善的经验。
    所以，再次看到SOA的的第一条准则：“业务驱动服务、服务驱动技术”的时候，深有感触。这才是问题的本源，原来的几次讨论和想法，其实都偏离了轨道。