1樓：Owen X
user story用來定義業務邊界，描述目標使用者在特定場景中的業務需求，可以不涉及產品或系統。回答做什麼的問題。
use case使用者定義系統邊界，描述使用者與產品/系統如何互動，以滿足需求，用來進行產品/系統設計。回答怎麼做的問題。
2樓：張克強
早年的Use Case是不控制顆粒度的，典型的CRUD是可以寫在乙個用例裡面的。因而當採用敏捷短迭代時，會出現在乙個迭代之內不能完成乙個用例。
而用例本身的定位是場景的抽象，場景是用例的例項化，多個場景抽象成乙個用例，乙個用例可以例項化出多個場景。
而使用者故事天生就是適合敏捷短迭代的。 如果對應到用例，使用者故事就是用例的場景，一般只是乙個場景。
使用者故事的優點：顆粒度小，利用自然語言描述，容易寫，也容易懂。
對於「使用者故事是面向價值，而用例是不面向價值」 這樣的評價，我認為是不對的。
兩者都是有效的需求表達方式，而且極為接近，用例中的Actor與使用者故事中的使用者就是相同的角色，都可以根據角色的業務需要，追求業務價值。
在使用中如何追求價值，就是使用的問題。
3樓：li有晴
請問：專案需求（或產品需求）是否通過使用者場景、業務模式、體驗習慣等通過一系列有效資訊進行一一關聯出User Stroy和Use Case嗎？
4樓：湯海
user story是從產品角度看待使用者，幫助你了解使用者使用某種產品的目的、任務、流程、情節等等。story本身不一定有嚴格的形式、規則（當然，故事寫得好會有很大幫助）。設計師、產品人員用得多一些。
可能尤其適合新產品的構思。
use case更多的是面向需求人員和開發人員，設計師有時也需要。use case偏重邏輯、次序。use case寫得好，需求會相當省力。
5樓：
在我的工作中，case只是作為質量判定來使用，那麼在我的設計思路下，通過good user case和bad user case來制定質量評定標準從而進行效果評定工作。
而story，在產品設計前，通過使用者調研得到的，指導產品設計工作的東西。在story下，我們會更進一步地細化到scenario
簡而言之，case是產品上線後，小的簡單的，用於質量評定和優化工作的東西；story則是在產品設計之前的，指導產品設計的東西。
6樓：羅義
User story在Scrum敏捷開發中是從stakeholder的角度描述相應業務功能的業務價值，並可以在Sprint中作為乙個交付件
7樓：
Use Case(用例) ：在不展現乙個系統或子系統內部結構的情況下，對系統或子系統的某個連貫的功能單元的定義和描述。
User Story(使用者故事)：描述對軟體（或系統）使用者或客戶有價值的功能,只是需求描述，而不是詳細的需求規範。.
推薦此位址參考http://
區別不了an和ang，en和eng，in和ing怎麼辦？
Kai Yung 先誇張地練習，把前鼻音發得更靠前，後鼻音發得更靠後，找到感覺再字正腔圓地加入聲調與聲母 抱歉。我讀著怪怪的 最後再用含有前後鼻音的句子 好久沒持續使用普通話交流超過3分鐘了。都生疏了。隨緣吧 上次長時間用普通話交流，也不過是有個外地人初到深圳問路罷了。大概就這樣發音，反正這樣發音不...
請問on the table 和at risk和in his pocket是賓補？雙賓？狀語 為什麼？
l origine 根據 張道真實用英語語法 的 1.3.2 可知 賓語即動作的承受者，或動作的結果。根據 張道真實用英語語法 的 21.1.1 可知 賓語分為直接賓語 間接賓語 復合賓語 帶有補語的賓語，也叫做賓補 三種。根據 張道真實用英語語法 的 21.2.1 可知 復合賓語 賓補 的第五種的...
WorkFlowy 和 Dynalist 和Bear 以及幕布，大綱筆記軟體工具你更喜歡哪個？
侃爺 都2020年了，由於Roam Research的出現，Workflowy 幕布 Dynalist瞬間變成了 傳統 的大綱筆記，感覺就是上個世紀的產物一樣。Roam Research需要科學上網和高昂月費，Obsidian不是基於block的，RoamEdit當前是國內Roam類第一的存在 Wo...