那邊把需求收集過來，然后需要利用自己的語言來對問題進行描述。若在這個描述的過程中，CIO站在自己的角度去思考，則往往會引起一些不必要的歧義。筆者認為，CIO在整理需求的時候，最好能夠站在用戶的角度去思考問題。同時，需求整理好后，最好能夠把自己整理的需求再讓用戶去確認一遍。讓他們審核一下，看看書面需求分析與他們的想法是否有出入。
　　二是在需求描述中，最好能夠配有實際案例。有時候，有些需求確實很難描述清楚?；蛘咭驗檎Z言組織的不好，以及文化、工作背景的不同，不同的人看需求報告確實會產(chǎn)生不同的理解。為此，筆者認為，最好能夠在需求中配上具體的案例。通過案例描述來把需求認識的歧義降至到最低。如當CIO描述“銷售訂單來對物料進行追蹤”這個需求時，可以配上具體的案例。例如企業(yè)有一張銷售訂單，分別生成四張采購訂單，需要購買A、B、C、D四個物料。其中，A物料因為倉庫中有庫存，所以采購沒有下采購訂單。而第二張采購訂單因為采購人員操作不小心刪除了，其后來手工補了一張采購訂單。C物料一半用庫存，一半采購。D物料后來利用其他物料來代替。把企業(yè)用戶碰到的實際情況一一利用案例描述出來。如此的話，無論是誰，看到這個案例也就明白了需求中具體描述了什么內(nèi)容。很明顯，通過這個案例描述可以在很大程度上消除CIO與程序員或者外部實施顧問認識上的分歧。
　　所以，筆者建議，CIO在巴自己的需求報告拿給別人看的時候，先要捫心自問，看看這份需求報告會不會十個人看得出十個不同的結(jié)果。若不幸真的是如此的話，那么CIO就應(yīng)該想出一些可行的措施，把這個歧義降低到最低。
　　問題三：是否詳細定義了可靠性？
　　在考慮需求分析報告是否可以過關(guān)的時候，還需要考慮一個問題，就是要衡量一下這個需求的可靠性問題。如這個需求執(zhí)行過程中會不會失敗，以及失敗會否給其他業(yè)務(wù)帶來什么樣的不利后果。同時，當失敗時系統(tǒng)以何種形式來告知管理員這個失敗的結(jié)果，等等。
　　如仍然是上面這個需求。現(xiàn)在在根據(jù)銷售訂單生成采購訂單的時候，由于一些原因可能銷售訂單無法按物料清單展開而正確生成采購訂單。如可能系統(tǒng)中某個物料有庫存，所以某個物料就沒有發(fā)生采購；又如可能某個原材料沒有定義供應(yīng)商，所以系統(tǒng)無法為這個供應(yīng)商生成采購訂單等等。
　　CIO在需求分析的時候，應(yīng)該預見這些情況可能會發(fā)生。那么，CIO就需要從程序的可靠性出發(fā)，想出一些應(yīng)對的措施。如因為有庫存而沒有下采購訂單，這是屬于正常的作業(yè)。但是，此時系統(tǒng)應(yīng)該以某種形式來告知用戶這種情況。如在生成采購單的時候通過日志信息記錄等等都是可以的。而因為沒有定義供應(yīng)商而導致采購訂單無法下達，此時，就需要系統(tǒng)通過非常明顯的方式告知企業(yè)用戶因為什么什么原因而導致采購訂單無法下達?？傊?，當因為一些意外情況，導致某個流程被意外中斷時，無論是合法的還是不合法的，系統(tǒng)都要能過以明文的形式告知用戶。否則的話，根據(jù)這個需求開發(fā)的解決方案的可靠性就會受到質(zhì)疑。
　　同時，這個提示信息業(yè)要盡量的讓人看的明白。如筆者發(fā)現(xiàn)有些系統(tǒng)在設(shè)計上確實也考慮到了這個可靠性問題，但是他們沒有更進一步，讓用戶頭疼不已。如因為沒有供應(yīng)商而導致無法正常生成采購訂單的時候，系統(tǒng)只提示“采購訂單無法生成”。即沒有告訴用戶因為什么原因?qū)е虏少徲唵螣o法生成；同時也沒有告訴用戶哪些原材料無法生成采購訂單。如此的話，用戶就需要從頭開始去查找錯誤的原因。其實，到底為什么無法生成采購訂單的原因，在后臺程序判斷中都會有所體現(xiàn)。只需要用戶把判斷的參數(shù)，如某個編號的零件供應(yīng)商ID為空等等信息反饋到前臺。那么系統(tǒng)管理人員憑借這條信息就可以非常容易的定位錯誤信息。并在最短時間內(nèi)把問題解決掉。
　　所以筆者認為，CIO在做需求分析的時候，除了要做好具體的需求描述之外，最好還要從這個可靠性出發(fā)，考慮發(fā)生意外事故時所需要傳遞的故障信息、錯誤檢測以及恢復策略等等。并且，這些信息要能夠幫助用戶迅速定位并且解決問題。即要反映出問題發(fā)生的原因而不能夠只是結(jié)果。

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html