作为一名软件开发人员，特别是服务器端开发来说，要关注方方面面的事情，但是并不是说其他类型的开发人员，例如客户端的开发，这类关注的事情会少许多，不！同样有很多很多事情需要操心。

这些事情促成了一个系统一套软件的形成，从最初的需求、概要设计、详细设、编码、测试一直到交付、验收。每个环节都需要关注，对于这样的流程，有很多方式去完成，大的不去说了，包含的东西实在太多，无法方方面面的去评述。最近思考了许多东西，想要好好整理一下，先笼统的从开发人员的角度来看，从最源头开始考虑起来，比如需求。

需求的定义，已经很明确了，三个层次： 业务需求 、 用户需求 、 功能需求 。

a) 业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

我理解的业务需求，应该是站在比较高的高度上去描述的，可以用几句话来描述系统的Why 和What。例如本人参与过的几个项目，非常笼统的描述，某区人事管理系统，或者OA 管理系统，解决本行政区某管理部门的人事管理，或者解决办公无纸化、系统化。典型的提纲挈领，这里的Why就是要解决的问题，是Vision。 What是需要开发的系统，也可以说是Scope。这两点可以使用很多方式描述，基本的方法就是画大饼，做个什么PPT，Chart之类的，可以很好的描述出来，大致的方向和任务也已经明晰了，所谓的Aim已经有了，从这里画条线到Aim，就是主线，初步的问题解决。

b) 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。

这部分的定义也很明确，如果有这么一个系统，那使用者们能干些什么呢？各种角色或者各种OBJECT，都能做什么事情，完成什么任务，用起来是怎么样的，看起来是怎么样的。听起来好像是产品经理干的活，也可以做点PPT或者Chart，来描述系统的UI，流程，Feature等等。这部分要收集，要思考。再说几个本人经历的，Ecommerce 的网站和企业内部的系统结合的故事，这里面，由于行业的特点，有很多需要收集和询问的需求。

c) 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

这个以本人的经历来说，主要是从开发者的角度去看，提取模块、模块中的业务模型，这些业务模型的相互作用等。这类东西相对来说标准化的很多，看看那些开源项目就可以有一个很清楚的蓝图。解决一个数据库ORM 问题，可以有很多库去参考，一堆的Feature List，就是功能需求。因此功能需求是基于用户需求而来的。

了解了这些定义，还不是最主要的，主要问题是如何获得这些需求，使用什么方法，使用什么工具，如何展示得更清晰。

• 文档，这个是必不可少的，文字描述，定义一些，描述一些，结构一定要清晰，分类分层是个好办法，容易记忆，也更直观。使用业务和用户需求。

• 使用UML从几个层面去描述业务逻辑，动态的静态的，做成chart，仔细研究，使用于开发需求。

• Prototype，好多软件Axure， Pencil等，直接画出来。

以上是工具，具体如何做，慢慢学习，改进，再学习，再改进。这个就是方法层面上的，本人特别喜欢的迭代，话说迭代可以用在开发上，亦可以用在需求挖掘上，每一次的Review挖掘更多需求， 用工具记录下来，用文档描述出来，用图片画出来。

另外一个就是脑图，发散性的去思考，获取更多隐藏需求。

工具和方法都是必要的，原始的材料在这个阶段获取，尽量在已定的scope内将需求尽最大可能全面和精细。注意scope，避免无限制的变化，不要跌倒焦油坑里面。

“需求”这个词本身也包含了2个方面，“需” 意味着要求的事物，我们要什么，“求” 意味着要求，我们需要的东西要达到某种程度。本人喜欢纵横比较，需求列表一要在横向上列出不同的任务需要，纵向上要明确写出任务的程度。

注意，在需求阶段，最好分清楚需求的种类，到底是业务的，用户的还是开发的，虽说可能描述的是同一个事情，但是在不同层面，表现的形式会不一样，很有可能造成团队中对问题认识的分化，在本人的项目管理经历中，出现过类似的问题，解决的问题是对于不同的人，不同的角色，以不同的形式阐述问题，对业务来说，使用原型具象化。对开发来说，抽象化，以开发特有的工具和形式来表现。

以上只是本人工作中碰到问题后总结出来的，当然，问题天天多，在慢慢的一个一个解决的同时，也停下来思考过，学习过，通过这种方式，再结合实际，发现效果也非常明显，简单来说，能够提高效率的事情，能够提高效率的工具，一定要去做，一定要去用。