網(wǎng)上很多類似需求分析的帖，還有少許高人掛名，無非都是寫些抓住顯性需求，深挖隱性需求之類云云，再問的深入點(diǎn)的話回答多半就是結(jié)合實(shí)際項(xiàng)目分析等等。有時(shí)候大道理看多了會(huì)讓人有深陷泥濘的感覺，在面對(duì)實(shí)際項(xiàng)目時(shí)就有點(diǎn)找不到出路?，F(xiàn)在我就說點(diǎn)實(shí)際的，談?wù)勎以陧?xiàng)目中所遇到的問題。
在實(shí)際項(xiàng)目中，需求一般經(jīng)歷三個(gè)活動(dòng)，即：評(píng)審、基線和變更；相對(duì)應(yīng)的測(cè)試活動(dòng)有：評(píng)審、用例和測(cè)試，具體時(shí)間點(diǎn)的對(duì)應(yīng)分別是需求評(píng)審中、需求基線后和需求變更前后，當(dāng)然在需求變更完成后也會(huì)穿插一些用例修改工作。
我們先來看看測(cè)試三項(xiàng)活動(dòng)中，哪一個(gè)環(huán)節(jié)最重要。我之前寫過這么一句話，叫做：方法影響用例，用例指導(dǎo)執(zhí)行，執(zhí)行顯示結(jié)果。當(dāng)然，方法自在人心，由此可見用例很重要。用例一般在需求基線后進(jìn)行編寫，但實(shí)際項(xiàng)目中由于項(xiàng)目緊急，PM就希望在需求基本邏輯穩(wěn)定后先同步進(jìn)行編寫用例，之后再根據(jù)需求變動(dòng)而修改相應(yīng)的測(cè)試用例。在這里我比較贊賞的是用例前置這么一個(gè)好的提議，但是我個(gè)人又不太認(rèn)可這么一個(gè)做法。
首先根據(jù)缺陷放大模型，我們肯定是希望能夠?qū)⑺锌赡苡|發(fā)的缺陷給扼殺在搖籃里，即在需求評(píng)審的時(shí)候就提出相應(yīng)的問題，我們都知道，編寫測(cè)試用例是發(fā)現(xiàn)需求問題的一個(gè)重要手段，那么如果我們?cè)谛枨蠡€后再去寫測(cè)試用例，那么就一定會(huì)有更多的需求問題會(huì)在開發(fā)那里衍生成為系統(tǒng)缺陷，所以我贊賞用例前置這個(gè)提議。
但是這樣一來，另外一個(gè)問題就擺上臺(tái)面了。基線前編寫好的測(cè)試用例在需求基線之后的修改量是十分巨大的，而且在某些需求大改動(dòng)的地方，我們只有選擇重新編寫用例，因?yàn)闅v史用例會(huì)禁錮我們的思想導(dǎo)致測(cè)試點(diǎn)缺失。這不僅僅是一個(gè)工作量的問題，它同樣會(huì)誘發(fā)消極怠工情緒，這也是為什么我并不大認(rèn)可需求基線前就編寫測(cè)試用例。
有時(shí)候人真是一個(gè)矛盾綜合體啊，下面談?wù)勎业淖龇?。首先我需要充足的評(píng)審時(shí)間，因?yàn)槲倚枨笤u(píng)審的時(shí)候會(huì)看的相當(dāng)仔細(xì)，不僅關(guān)注基本的邏輯問題、措辭嚴(yán)謹(jǐn)問題，還關(guān)注角色權(quán)限、功能入口、返回界面、默認(rèn)排序、字段長(zhǎng)度、字符限制、流程的合理性已經(jīng)相應(yīng)UI原型布局、交互、菜單層級(jí)之類的問題，將寫測(cè)試用例時(shí)所想的在評(píng)審的時(shí)候發(fā)揮出來，以便理清需求、盡早的發(fā)現(xiàn)更多的問題，這時(shí)候用例不會(huì)寫出來，但是在腦海里應(yīng)該有個(gè)大概的輪廓。用記事本記錄所有問題，時(shí)刻關(guān)注需求文檔的修改，并實(shí)時(shí)將最新版本需求文檔與之前版本的需求文檔在SVN中進(jìn)行對(duì)比，確保自己關(guān)心的問題得到修改，并記錄他人提出的修改意見在需求中的修改情況，并根據(jù)相應(yīng)的修改情況重新整理腦海中用例的映射集，在需求基線后就可以用最快的方式寫出最完整的測(cè)試用例。
合理的需求分析還應(yīng)該結(jié)合一個(gè)合理的功能點(diǎn)劃分，一般情況下我們功能點(diǎn)的劃分直接按照工作量來劃分，其實(shí)還應(yīng)該結(jié)合功能點(diǎn)之間的關(guān)聯(lián)程度、相應(yīng)需求人員的分工以及相應(yīng)測(cè)試人員的能力進(jìn)行劃分。具體原因細(xì)節(jié)我不愿在這過多累述，雖然在實(shí)行上有些困難，但是我覺得這個(gè)大致方向是可取的。