整理什么是需求， 什么是功能。

 即使学过软件工程， 但，如果不亲身体会，依然对每个环节体会不深，从工作经验来看， 个人认为， 软件工程有时空环境，针对十人级的团队开发说话：

1。PM ＋ GP1 （第一组人）做调研，整理出用户需求文档
2。 PM ＋ GP1 与用户确认需求文档 ， 定档。
3。 PM +  Gp2 （第二组人）从需求文档中，整理出 概要设计，这部分文档，包括两部分（一是从需求演变而来的功能文档 ， 二是从功能文档演变而来的对功能实现的描述，就是软件架构和及实现框架。）
4。 PM ＋ Gp3 （第三组人）从概要设计中扩展成 详细设计文档。这一部分是对概要设计的完善，是它的扩充，是它的大集合。
5。 PM + Gp3 (第三组人） ，编码。

     这五步有时间顺序，如果项目先做了概要设计，后补了需求， 个人认为， 真的没什么必要。
     有空间约定，在第一阶段做需求的人，是专门完成需求的。在这一阶段， 只有在这一阶段，做需求才有意义，这时， 不应该有人在编码。
 
     为什么每一步都有 PM 呢。 因为，对于第一步来说，都要组织不同的人去做， 来制作每一步的标准， 都要有一个人来验收，说， 这一步可以了。 PM 的职责是组织资源，制作标准， 业绩考核，把握整体进步。PM 所带领的每一组人，有一个 组长（TeamLeader) 带协助PM 完成每一阶段的工作。 这个组长（TL）也很重要，他能完成这个阶段的重点和难点。 如果没有这个 TL ， 那就会让 PM 疲于奔命！ PM 形同虚设！从这个模型来看， 一个 PM 需要三个 TL ，每个TL 有两个到四个人，形成十人级团队。

  在需求和功能 方面 ， 非常认同 黄国强 的观点。
     软件需求关注的是做什么的问题，而软件功能关注的是怎么做的问题。
     软件需求是为用户服务的，而软件功能是为软件开发服务的。
     相对于软件需求这个目的，软件功能是手段。

     唠叨几句， 关于需求文档的话题，一些领导很强调需求文档 ，应该是为了招投标而写的标书，或为了产品交付验收用的。在我工作的项目里，有相当一大部分（如果用数字来描述的话，要达到 60％以上）是先不写需求文档的，不是不想写，项目时间很紧，根本不允许，鞭打快驴，越快越打，是中国管理人的风格。程序员关注的是概要设计，他们所需要了解的需求，可以跟他们几句话说清。但是， 事实上， 有多少人真的这么做了呢。 这一套下来所花的成本，有多少投资者能够接受。三个月出一个项目的做法， 导致过程畸形！ ， 最常见的是紧急的开工， 后补的文档 。这样的文档好写，但是没啥用处。

后注：
   1。  原文，5。是第四组人， 我想，应该修改成第三组人， 往往的情况是 文档写到概要设计，就OK了。简单的跟程序员一说，程序员就知道怎么做了。如果真写到详细设计文档，那也剩不下多少活了。详细设计可以做为程序员的开发笔记， 这样，PM 和 TL 看到详细设计后，就很容易读懂程序员的思路，很容易发现问题。
   2。 这五步，应该是每一步跟上一步会有一个小的反复，形成一个小螺旋，这样的反复是值得的， 而且是卓有成效的，它会让开发人员跟着步调走，形成合力。在非常必要的时候，可能从头到尾都要变动，这样就形成一个大螺旋 。比如，为了使用新技术，为了用户的可配置性，为了用户的插件式结构，二次开发等， 软件是需要重构的， 同样，过程也是需要重构的。毕竟，了为一个目的， 那就是要做的更好。


引用：讨论如何写需求文档 http://www.javaeye.com/topic/178200
引用：软件需求和软件功能的区别 http://blog.csdn.net/acloudhuang/archive/2008/08/28/2842918.aspx
引用：什么是需求说明的质量特性 http://www.cnblogs.com/mayingbao/archive/2006/10/15/529282.html