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