可以避免。
敏捷中非常推崇的方法，但多数敏捷方法只提到了故事，而较少谈及场景。
即使不使用敏捷，也可以使用这种方法。
简介：
故事只有一句话，但却很好地表达了几个重要内容，比如（银行软件）“三次密码错误锁定”这个功能会写成“作为用户，我希望在取款时尝试密码第三次错误后锁定账号，以防止有人恶意尝试我的帐号密码。”角色-操作-目标 是故事中最重要的三个要素。很多传统的需求描述方法文字冗长，却未能覆盖这三个要点。
场景呢，则是某种应用环境，围绕场景可以发生若干故事。比如“取款”就是一种场景，包括了密码正确正常取款/密码可以重试两次/三次密码锁定等若干故事。
以下产品与之匹配：有一定的创意，很希望通过创意生成故事，进而增进产品的功能。
几个明显地是应该选择这种需求结构的判定条件：
1. 产品的吸引力不在于功能多少（否则应该用上面的文件-操作型），而是实现到何种程度（故事中的“目标”）
2. 针对一种场景，可以想象很多故事以增进产品价值（简直是无穷的，因此需要排列优先级）
使用这种需求结构应该注意的地方：
1. 故事必须是一个能/也必须整体交付的功能，这是故事的一个天然颗粒度把握方法。
常见问题：
1. 故事写得不好。问题很多，买本书看看：用户故事与敏捷方法 http：//www.china-pub.com/196596。很可惜，里边没有怎么提到用户故事如何组织。
更详细的内部结构：
1. 很多场景各自还包含若干个层次
成功要诀：
1. 一定要面向用户价值描述用户故事，否则经常无法达到预期效果。比如一款杀毒软件，每次安装其他软件时，需要多次修改注册表和硬盘，因此弹出的拦截界面很多；尽管可以选择“相同操作不再提醒”，但仍然弹出。因为用户理解的“相同操作”（同一个软件的安装过程中）和程序员理解的“相同操作”（同一个注册表项的修改）不同。
用例型
UML的方法。
没好好学过UML，所以也不太清楚。
只记得非常重要的一句话：只描述那些对客户有价值的用例，登录/修改密码/XXX都别写（潘家宇说的）。
从这一点上看，UML的组织方法是面向开发团队的。
想想也是，别看都是图形化的，UML可真不是写给客户看的，包括UC图。而且UC图下面马上接上的是Sequence等技术图，如果一个UC下面没有或者不必要画那些技术图，这个UC也就可以消失了。