http://localhost:8888/FitNesse.UserGuide. ProjectDeathByRequirements
怎样弄死软件项目
有好多方式能够弄死项目，但我们这里就提一种最普遍的方式。如果你在软件开发活动中有段时间的话，你会发现常看到下面的场景：
软件发行
有着世界上最好想法，充满智慧的开发团队，满是兴奋和最高的期待的对待着一个项目。
用英文文档的形式来整理收集到的所有系统需求。包括so many的图表，设想的用户界面、场景截图还有其他的文本资料。
设计、开发。
时间慢慢走过。
黑盒测试。
出错了…靠！
问题！
我们不时的发现下面描述到的问题，它们通常在项目后期，或者发现其他问题的时候被发现。
所实现的功能不是用户或分析人员真正想要的。
所实现的功能不是人民群众需要的。
所实现的功能没什么作用。
子系统不能被整合到其他系统里去，因为他们的接口设计不合适。
对于问题，团队成员出现分歧。(“我就是按你说的去做的！”“不，你没有！你从没按我说的去做”)人们变的很火大；团队成员的积极性在减退。
项目管理参与了进来：
急救会议被排上日程。会被开的很长，会议也开的很严肃。
大家开始加班。人们在呼喊“救救我们的系统！！”
英雄出现了，但还是不像想象的那么完美。最后期限和系统依然在悲剧中。
还有什么呢？到底出了什么问题？我们怎么走到了这样的地步！！！？？？
嘛地方出错了
很多问题是这样发生的：当时的情况是这样的- -
我们描述的需求的语言问题，它们不够严谨，就像是我们去晒太阳，对还是错呢。开发团队被文字误导了，需求被理解错了。(除了图标，设想的界面等)
整个开发过程中获取的反馈信息太少了。闭门造车？？
团队获取特性反馈不够早。
项目中，团队获取特性频率太底，别人改了咱都不知道。
事后，基于界面的手工测试(除非它是超大量的)执行了大量对系统逻辑的路径测试。这样的测试会漏掉系统大量需要测试的地方。开发团队对于做好的系统特性就只能得到很少的信息。
需求描述和可执行的验收测试是必须的和有效的，它们能保证系统是完整的，精确的和决定的。
使用FitNesse验收测试，你可以避免上面的问题
来看看吧！
