故事如何區別于其他三種常見的需求方法：用例、IEEE830軟件需求規格、交互設計場景

一、用戶故事不是IEEE830

IEEE830軟件需求規格，最突出的特征是使用短語“系統應該........”,側重于關注需求的堅持清單，而不是用戶的目標。在寫下所有需求前，每個需求的成本是不可見的。

IEEE830是需求列表，故事則描述用戶目標。

用戶故事不是分析活動的產物，相反，用戶故事是進行分析的支持工具。

?

二、用戶故事不是用例

用例是對系統之間以及一個或者多個用戶之間交互的一般性描述，使用者要么是用戶，要么是另外的系統。

用戶故事和用例區分：

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

2.完整性：故事對應用例的主要成功場景，而故事測試對應于用例拓展

3.壽命：用例常常作為永久性“工作”持續存在，存在于整個開發過程中。故事一般不會超過包含他們的迭代。

4.用例比較容易包括用戶界面的細節（會導致問題）

5.目的：用例的目的是記錄客戶和開發團隊之間的協議，而編寫用戶故事是為了更方便發布計劃和迭代計劃，并且它充當著用戶具體需求對話的占位符。（用例被編寫成方便開發人員和客戶討論并達成共識。用戶故事編寫成方便計劃發布，并勇于提醒需求細節的討論）

?

三、用戶故事不是場景

場景是用戶與計算機交互的詳細描述。交互設計場景通常比用例更大或者更全面。

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

• 應用環境——故事發生的地方
• 使用者——每個場景中至少包含一個使用者
• 目標或者目的——場景中的每個使用者都可以尋求一個或者多個目標
• 行動和事件——場景的故事情節

用戶故事和場景區分：

1.范圍：場景包含更多的細節，他們的范圍通常涵蓋多個故事

2.細節：場景包含更多細節

總結

以上是生活随笔為你收集整理的用户故事与敏捷方法—故事不是什么的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。