无论是写成文档呢还是口头交流，都各有利弊。

写成文档的需求

-可以经过仔细思考，评审以及编辑

-可以永久保存

-可以方便的跟一组人分享

但是，

-需要很多时间去写

-随着时间的变化会变得过时

-很容易被误解

口头的需求

-可以即时反馈和澄清

-是信息的双向交流

-很容易解释和获得共识

-很容易适应新形势的变化

-可以激发灵感

但是，

-经常是不经过深思熟虑的

-不容易在一组人之间共享，特别是不在同一个地方的

-同样的谈话不同的人有不同的记忆

User Story则兼具两者的优点。

敏捷开发要求我们：

-用户要积极参与，以保证透明和及时反馈

-敏捷的团队需要充分授权，这样细节就可以在开发时补充

-开发过程中可以不断增加或修改需求

-敏捷的需求是不够的，需要在开发过程中不断补充细节，但是却可以很快写出来

-需求可以一小块一小块的完成，这样细节就可以口头完成，以免大家忘记了细节，或者需求讨论时有的人没有参加。

-足够就可以了。应用80/20原则；不需要把所有的细节都考虑清楚了才能做出一个合格的产品；口头澄清，看得见的软件，以及反馈才是最好的。

-团队成员之间的合作和交流才是最重要的，每个相关的人都必须了解需求讨论的结果。

原文链接：

Software Requirements are a Communication Problem

发表于 @ 2008年03月11日 19:45:00|评论(loading...)|编辑