用户故事与敏捷方法—故事不是什么

故事如何区别于其他三种常见的需求方法：用例、IEEE830软件需求规格、交互设计场景

一、用户故事不是IEEE830

IEEE830软件需求规格，最突出的特征是使用短语“系统应该........”,侧重于关注需求的坚持清单，而不是用户的目标。在写下所有需求前，每个需求的成本是不可见的。

IEEE830是需求列表，故事则描述用户目标。

用户故事不是分析活动的产物，相反，用户故事是进行分析的支持工具。

 

二、用户故事不是用例

用例是对系统之间以及一个或者多个用户之间交互的一般性描述，使用者要么是用户，要么是另外的系统。

用户故事和用例区分：

1.范围：故事的范围更小

2.完整性：故事对应用例的主要成功场景，而故事测试对应于用例拓展

3.寿命：用例常常作为永久性“工作”持续存在，存在于整个开发过程中。故事一般不会超过包含他们的迭代。

4.用例比较容易包括用户界面的细节（会导致问题）

5.目的：用例的目的是记录客户和开发团队之间的协议，而编写用户故事是为了更方便发布计划和迭代计划，并且它充当着用户具体需求对话的占位符。（用例被编写成方便开发人员和客户讨论并达成共识。用户故事编写成方便计划发布，并勇于提醒需求细节的讨论）

 

三、用户故事不是场景

场景是用户与计算机交互的详细描述。交互设计场景通常比用例更大或者更全面。

场景包括以下特征性元素：

• 应用环境——故事发生的地方
• 使用者——每个场景中至少包含一个使用者
• 目标或者目的——场景中的每个使用者都可以寻求一个或者多个目标
• 行动和事件——场景的故事情节

用户故事和场景区分：

1.范围：场景包含更多的细节，他们的范围通常涵盖多个故事

2.细节：场景包含更多细节