需求分析的重要性，筆者相信已經(jīng)深入人心。如何做好需求調(diào)研，大家說(shuō)起來(lái)也已經(jīng)一套一套了。筆者這里從另一個(gè)層面來(lái)談?wù)勑枨蠓治?，即如何?lái)判斷你需求是否可以過(guò)關(guān)。筆者試圖通過(guò)三個(gè)問(wèn)題，來(lái)檢驗(yàn)?zāi)阈枨蠓治龅馁|(zhì)量是否可以站得住腳。

　　問(wèn)題一：需求是否已經(jīng)考慮到了所有的應(yīng)用場(chǎng)景？

　　CIO在需求調(diào)研時(shí)，務(wù)必要根據(jù)企業(yè)的實(shí)際情況來(lái)進(jìn)行需求的描述。也就是說(shuō)，在需求報(bào)告中，不要只簡(jiǎn)單的描述用戶(hù)所需要達(dá)到的結(jié)果，而是還要定義清楚實(shí)際的應(yīng)用場(chǎng)景，而且要全面。因?yàn)橥煌膽?yīng)用場(chǎng)景會(huì)導(dǎo)致不同的解決方案。

　　如CIO通過(guò)調(diào)查發(fā)現(xiàn)，員工需要根據(jù)銷(xiāo)售訂單來(lái)對(duì)物料進(jìn)行追蹤。也就是說(shuō)，員工希望能夠在系統(tǒng)中看到，某帳銷(xiāo)售訂單是否已經(jīng)下了采購(gòu)訂單；采購(gòu)訂單上的預(yù)計(jì)交期是多少；現(xiàn)在到料的情況如何，等等。

　　這個(gè)需求描述是否夠詳細(xì)了呢？筆者以前認(rèn)為，這已經(jīng)非常的詳細(xì)。因?yàn)槲野盐覀冃枰裁礃拥慕Y(jié)果都一一列舉出來(lái)。但是，隨著幾年CIO工作下來(lái)，現(xiàn)在再回頭看看，才發(fā)現(xiàn)這個(gè)需求描述很難過(guò)關(guān)。因?yàn)槠潆m然描述了我們所需要達(dá)到的目標(biāo)，但是，他沒(méi)有反應(yīng)出企業(yè)的實(shí)際應(yīng)用場(chǎng)景。筆者認(rèn)為，在這個(gè)需求描述中，我們至少還需要說(shuō)明如下問(wèn)題。

　　一是當(dāng)企業(yè)正常下采購(gòu)訂單，即從銷(xiāo)售訂單生成采購(gòu)訂單，然后再?gòu)牟少?gòu)訂單生成收貨單。在這種應(yīng)用場(chǎng)景下，那么該如何來(lái)收集統(tǒng)計(jì)這一連串的信息。因?yàn)樗麄儽舜酥g是前后有關(guān)聯(lián)的，實(shí)現(xiàn)起來(lái)比較方便。

　　二是若企業(yè)存在手工下訂單的情況，該如何來(lái)顯示這個(gè)關(guān)聯(lián)特性。如企業(yè)在維護(hù)采購(gòu)訂單的時(shí)候，因?yàn)椴恍⌒陌涯硰埐少?gòu)訂單刪除了；后來(lái)又手工補(bǔ)了一張采購(gòu)訂單。此時(shí)，手工補(bǔ)的采購(gòu)訂單與銷(xiāo)售訂單就會(huì)失去聯(lián)系。根據(jù)銷(xiāo)售訂單就無(wú)法追蹤到這種采購(gòu)訂單的信息。CIO在收集需求的時(shí)候，也要把這種情況反饋給軟件實(shí)施顧問(wèn)或者程序員，讓其能夠預(yù)先找到措施來(lái)應(yīng)對(duì)這個(gè)問(wèn)題。其實(shí)，只需要在采購(gòu)訂單單頭設(shè)立一個(gè)字段。當(dāng)用戶(hù)手工開(kāi)立采購(gòu)訂單的時(shí)候，去關(guān)聯(lián)銷(xiāo)售訂單即可。實(shí)現(xiàn)起來(lái)很發(fā)現(xiàn)。但是，若CIO不把這個(gè)企業(yè)會(huì)實(shí)際碰到的情況告訴給他人的話(huà)，則他們就不會(huì)尋找可行的解決方案。那么當(dāng)企業(yè)實(shí)際遇到這個(gè)問(wèn)題時(shí)，企業(yè)就束手無(wú)策了。

　　三是是否會(huì)存在不下采購(gòu)訂單的情況。如可能某個(gè)物料有庫(kù)存，所以系統(tǒng)在考慮物料需求計(jì)劃的時(shí)候，就沒(méi)有考慮到這個(gè)物料。所以，在生成采購(gòu)訂單的時(shí)候，當(dāng)然也不會(huì)把這個(gè)物料考慮進(jìn)去。此時(shí)，就會(huì)引發(fā)另外一個(gè)問(wèn)題。因?yàn)楦鶕?jù)上面的需求描述，這個(gè)需求是按照銷(xiāo)售訂單、采購(gòu)訂單、物料收貨單這個(gè)鏈條下去的。若沒(méi)有采購(gòu)訂單的話(huà)，這個(gè)中間的鏈條就斷裂了。那么當(dāng)用戶(hù)去查詢(xún)的時(shí)候，就會(huì)有這個(gè)疑問(wèn)：為什么沒(méi)有這個(gè)物料呢？是否是采購(gòu)?fù)浵虏少?gòu)訂單了呢？不少企業(yè)出于安全生產(chǎn)的需要，往往會(huì)備有安全庫(kù)存。當(dāng)安全庫(kù)存沒(méi)有降低到采購(gòu)點(diǎn)的話(huà)，則就不會(huì)發(fā)采購(gòu)訂單。CIO在需求分析的時(shí)候，若沒(méi)有把這個(gè)應(yīng)用情景描述出來(lái)，則這個(gè)需求分析仍然是不健全的。到時(shí)候程序開(kāi)發(fā)人員設(shè)計(jì)的解決方案，仍然不能夠涵蓋企業(yè)所有的應(yīng)用場(chǎng)景。

　　所以，除非CIO能夠拍拍胸脯自信的說(shuō)，所有已知的應(yīng)用場(chǎng)景都已經(jīng)在需求描述中一一列舉出來(lái)。否則的話(huà)，筆者勸各位CIO，還是暫時(shí)不要把這份需求報(bào)告拿出來(lái)丟人現(xiàn)眼為好。

　　問(wèn)題二：需求描述會(huì)給其它人帶來(lái)歧義嗎？

　　若CIO收集的需求描述，給不同的人看會(huì)有不同的結(jié)論，那么這個(gè)需求描述就不會(huì)有多大的實(shí)用價(jià)值。或者說(shuō)，這些需求分析還是不要做的好。因?yàn)榇藭r(shí)別人若按照你的需求描述去編寫(xiě)解決方案，那么反而是在做無(wú)用功。

　　那該如何減少這個(gè)需求描述所帶來(lái)的歧義呢？筆者認(rèn)為，各位CIO，可以借鑒以下的做法。

　　一是盡量從用戶(hù)的角度來(lái)考慮問(wèn)題。當(dāng)我們從用戶(hù)那邊把需求收集過(guò)來(lái)，然后需要利用自己的語(yǔ)言來(lái)對(duì)問(wèn)題進(jìn)行描述。若在這個(gè)描述的過(guò)程中，CIO站在自己的角度去思考，則往往會(huì)引起一些不必要的歧義。筆者認(rèn)為，CIO在整理需求的時(shí)候，最好能夠站在用戶(hù)的角度去思考問(wèn)題。同時(shí)，需求整理好后，最好能夠把自己整理的需求再讓用戶(hù)去確認(rèn)一遍。讓他們審核一下，看看書(shū)面需求分析與他們的想法是否有出入。

　　二是在需求描述中，最好能夠配有實(shí)際案例。有時(shí)候，有些需求確實(shí)很難描述清楚?；蛘咭?yàn)檎Z(yǔ)言組織的不好，以及文化、工作背景的不同，不同的人看需求報(bào)告確實(shí)會(huì)產(chǎn)生不同的理解。為此，筆者認(rèn)為，最好能夠在需求中配上具體的案例。通過(guò)案例描述來(lái)把需求認(rèn)識(shí)的歧義降至到最低。如當(dāng)CIO描述“銷(xiāo)售訂單來(lái)對(duì)物料進(jìn)行追蹤”這個(gè)需求時(shí)，可以配上具體的案例。例如企業(yè)有一張銷(xiāo)售訂單，分別生成四張采購(gòu)訂單，需要購(gòu)買(mǎi)A、B、C、D四個(gè)物料。其中，A物料因?yàn)閭}(cāng)庫(kù)中有庫(kù)存，所以采購(gòu)沒(méi)有下采購(gòu)訂單。而第二張采購(gòu)訂單因?yàn)椴少?gòu)人員操作不小心刪除了，其后來(lái)手工補(bǔ)了一張采購(gòu)訂單。C物料一半用庫(kù)存，一半采購(gòu)。D物料后來(lái)利用其他物料來(lái)代替。把企業(yè)用戶(hù)碰到的實(shí)際情況一一利用案例描述出來(lái)。如此的話(huà)，無(wú)論是誰(shuí)，看到這個(gè)案例也就明白了需求中具體描述了什么內(nèi)容。很明顯，通過(guò)這個(gè)案例描述可以在很大程度上消除CIO與程序員或者外部實(shí)施顧問(wèn)認(rèn)識(shí)上的分歧。

　　所以，筆者建議，CIO在巴自己的需求報(bào)告拿給別人看的時(shí)候，先要捫心自問(wèn)，看看這份需求報(bào)告會(huì)不會(huì)十個(gè)人看得出十個(gè)不同的結(jié)果。若不幸真的是如此的話(huà)，那么CIO就應(yīng)該想出一些可行的措施，把這個(gè)歧義降低到最低。

　　問(wèn)題三：是否詳細(xì)定義了可靠性？

　　在考慮需求分析報(bào)告是否可以過(guò)關(guān)的時(shí)候，還需要考慮一個(gè)問(wèn)題，就是要衡量一下這個(gè)需求的可靠性問(wèn)題。如這個(gè)需求執(zhí)行過(guò)程中會(huì)不會(huì)失敗，以及失敗會(huì)否給其他業(yè)務(wù)帶來(lái)什么樣的不利后果。同時(shí)，當(dāng)失敗時(shí)系統(tǒng)以何種形式來(lái)告知管理員這個(gè)失敗的結(jié)果，等等。

　　如仍然是上面這個(gè)需求?，F(xiàn)在在根據(jù)銷(xiāo)售訂單生成采購(gòu)訂單的時(shí)候，由于一些原因可能銷(xiāo)售訂單無(wú)法按物料清單展開(kāi)而正確生成采購(gòu)訂單。如可能系統(tǒng)中某個(gè)物料有庫(kù)存，所以某個(gè)物料就沒(méi)有發(fā)生采購(gòu)；又如可能某個(gè)原材料沒(méi)有定義供應(yīng)商，所以系統(tǒng)無(wú)法為這個(gè)供應(yīng)商生成采購(gòu)訂單等等。

　　CIO在需求分析的時(shí)候，應(yīng)該預(yù)見(jiàn)這些情況可能會(huì)發(fā)生。那么，CIO就需要從程序的可靠性出發(fā)，想出一些應(yīng)對(duì)的措施。如因?yàn)橛袔?kù)存而沒(méi)有下采購(gòu)訂單，這是屬于正常的作業(yè)。但是，此時(shí)系統(tǒng)應(yīng)該以某種形式來(lái)告知用戶(hù)這種情況。如在生成采購(gòu)單的時(shí)候通過(guò)日志信息記錄等等都是可以的。而因?yàn)闆](méi)有定義供應(yīng)商而導(dǎo)致采購(gòu)訂單無(wú)法下達(dá)，此時(shí)，就需要系統(tǒng)通過(guò)非常明顯的方式告知企業(yè)用戶(hù)因?yàn)槭裁词裁丛蚨鴮?dǎo)致采購(gòu)訂單無(wú)法下達(dá)?？傊?dāng)因?yàn)橐恍┮馔馇闆r，導(dǎo)致某個(gè)流程被意外中斷時(shí)，無(wú)論是合法的還是不合法的，系統(tǒng)都要能過(guò)以明文的形式告知用戶(hù)。否則的話(huà)，根據(jù)這個(gè)需求開(kāi)發(fā)的解決方案的可靠性就會(huì)受到質(zhì)疑。

　　同時(shí)，這個(gè)提示信息業(yè)要盡量的讓人看的明白。如筆者發(fā)現(xiàn)有些系統(tǒng)在設(shè)計(jì)上確實(shí)也考慮到了這個(gè)可靠性問(wèn)題，但是他們沒(méi)有更進(jìn)一步，讓用戶(hù)頭疼不已。如因?yàn)闆](méi)有供應(yīng)商而導(dǎo)致無(wú)法正常生成采購(gòu)訂單的時(shí)候，系統(tǒng)只提示“采購(gòu)訂單無(wú)法生成”。即沒(méi)有告訴用戶(hù)因?yàn)槭裁丛驅(qū)е虏少?gòu)訂單無(wú)法生成；同時(shí)也沒(méi)有告訴用戶(hù)哪些原材料無(wú)法生成采購(gòu)訂單。如此的話(huà)，用戶(hù)就需要從頭開(kāi)始去查找錯(cuò)誤的原因。其實(shí)，到底為什么無(wú)法生成采購(gòu)訂單的原因，在后臺(tái)程序判斷中都會(huì)有所體現(xiàn)。只需要用戶(hù)把判斷的參數(shù)，如某個(gè)編號(hào)的零件供應(yīng)商ID為空等等信息反饋到前臺(tái)。那么系統(tǒng)管理人員憑借這條信息就可以非常容易的定位錯(cuò)誤信息。并在最短時(shí)間內(nèi)把問(wèn)題解決掉。

　　所以筆者認(rèn)為，CIO在做需求分析的時(shí)候，除了要做好具體的需求描述之外，最好還要從這個(gè)可靠性出發(fā)，考慮發(fā)生意外事故時(shí)所需要傳遞的故障信息、錯(cuò)誤檢測(cè)以及恢復(fù)策略等等。并且，這些信息要能夠幫助用戶(hù)迅速定位并且解決問(wèn)題。即要反映出問(wèn)題發(fā)生的原因而不能夠只是結(jié)果。