可以避免。
敏捷中非常推崇的方法，但多數(shù)敏捷方法只提到了故事，而較少談及場景。
即使不使用敏捷，也可以使用這種方法。
簡介：
故事只有一句話，但卻很好地表達了幾個重要內(nèi)容，比如（銀行軟件）“三次密碼錯誤鎖定”這個功能會寫成“作為用戶，我希望在取款時嘗試密碼第三次錯誤后鎖定賬號，以防止有人惡意嘗試我的帳號密碼?！苯巧?操作-目標 是故事中最重要的三個要素。很多傳統(tǒng)的需求描述方法文字冗長，卻未能覆蓋這三個要點。
場景呢，則是某種應用環(huán)境，圍繞場景可以發(fā)生若干故事。比如“取款”就是一種場景，包括了密碼正確正常取款/密碼可以重試兩次/三次密碼鎖定等若干故事。
以下產(chǎn)品與之匹配：有一定的創(chuàng)意，很希望通過創(chuàng)意生成故事，進而增進產(chǎn)品的功能。
幾個明顯地是應該選擇這種需求結(jié)構(gòu)的判定條件：
1. 產(chǎn)品的吸引力不在于功能多少（否則應該用上面的文件-操作型），而是實現(xiàn)到何種程度（故事中的“目標”）
2. 針對一種場景，可以想象很多故事以增進產(chǎn)品價值（簡直是無窮的，因此需要排列優(yōu)先級）
使用這種需求結(jié)構(gòu)應該注意的地方：
1. 故事必須是一個能/也必須整體交付的功能，這是故事的一個天然顆粒度把握方法。
常見問題：
1. 故事寫得不好。問題很多，買本書看看：用戶故事與敏捷方法 http：//www.china-pub.com/196596。很可惜，里邊沒有怎么提到用戶故事如何組織。
更詳細的內(nèi)部結(jié)構(gòu)：
1. 很多場景各自還包含若干個層次
成功要訣：
1. 一定要面向用戶價值描述用戶故事，否則經(jīng)常無法達到預期效果。比如一款殺毒軟件，每次安裝其他軟件時，需要多次修改注冊表和硬盤，因此彈出的攔截界面很多；盡管可以選擇“相同操作不再提醒”，但仍然彈出。因為用戶理解的“相同操作”（同一個軟件的安裝過程中）和程序員理解的“相同操作”（同一個注冊表項的修改）不同。
用例型
UML的方法。
沒好好學過UML，所以也不太清楚。
只記得非常重要的一句話：只描述那些對客戶有價值的用例，登錄/修改密碼/XXX都別寫（潘家宇說的）。
從這一點上看，UML的組織方法是面向開發(fā)團隊的。
想想也是，別看都是圖形化的，UML可真不是寫給客戶看的，包括UC圖。而且UC圖下面馬上接上的是Sequence等技術(shù)圖，如果一個UC下面沒有或者不必要畫那些技術(shù)圖，這個UC也就可以消失了。