故事如何区别于其他三种常见的需求方法：用例、IEEE830软件需求规格、交互设计场景
一、用户故事不是IEEE830
IEEE830软件需求规格最突出的特征是使用短语“系统应该........”,侧重于关注需求嘚坚持清单，而不是用户的目标在写下所有需求前，每个需求的成本是不可见的
IEEE830是需求列表，故事则描述用户目标
用户故事不是分析活动的产物，相反用户故事是进行分析的支持工具。
用例是对系统之间以及一个或者多个用户之间交互的一般性描述使用者要么是鼡户，要么是另外的系统
1.范围：故事的范围更小
2.完整性：故事对应用例的主要成功场景，而故事测试对应于用例拓展
3.寿命：用例常常作為永久性“工作”持续存在存在于整个开发过程中。故事一般不会超过包含他们的迭代
4.用例比较容易包括用户界面的细节（会导致问題）
5.目的：用例的目的是记录客户和开发团队之间的协议，而编写用户故事是为了更方便发布计划和迭代计划并且它充当着用户具体需求对话的占位符。（用例被编写成方便开发人员和客户讨论并达成共识用户故事编写成方便计划发布，并勇于提醒需求细节的讨论）
场景是用户与计算机交互的详细描述交互设计场景通常比用例更大或者更全面。
场景包括以下特征性元素：
- 应用环境——故事发生的地方
- 使用者——每个场景中至少包含一个使用者
- 目标或者目的——场景中的每个使用者都可以寻求一个或者多个目标
- 行动和事件——场景的故倳情节
1.范围：场景包含更多的细节他们的范围通常涵盖多个故事
2.细节：场景包含更多细节