三個問題確認需求分析是否過關

申請免費試用、咨詢電話：400-8352-114

　　需求分析的重要性，筆者相信已經深入人心。如何做好需求調研，大家說起來也已經一套一套了。筆者這里從另一個層面來談談需求分析，即如何來判斷你需求是否可以過關。筆者試圖通過三個問題，來檢驗你需求分析的質量是否可以站得住腳。

　　問題一：需求是否已經考慮到了所有的應用場景？
　　CIO在需求調研時，務必要根據(jù)企業(yè)的實際情況來進行需求的描述。也就是說，在需求報告中，不要只簡單的描述用戶所需要達到的結果，而是還要定義清楚實際的應用場景，而且要全面。因為往往不同的應用場景會導致不同的解決方案。

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

　　這個需求描述是否夠詳細了呢？筆者以前認為，這已經非常的詳細。因為我把我們需要什么樣的結果都一一列舉出來。但是，隨著幾年CIO工作下來，現(xiàn)在再回頭看看，才發(fā)現(xiàn)這個需求描述很難過關。因為其雖然描述了我們所需要達到的目標，但是，他沒有反應出企業(yè)的實際應用場景。筆者認為，在這個需求描述中，我們至少還需要說明如下問題。

　　一是當企業(yè)正常下采購訂單，即從銷售訂單生成采購訂單，然后再從采購訂單生成收貨單。在這種應用場景下，那么該如何來收集統(tǒng)計這一連串的信息。因為他們彼此之間是前后有關聯(lián)的，實現(xiàn)起來比較方便。

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

　　三是是否會存在不下采購訂單的情況。如可能某個物料有庫存，所以系統(tǒng)在考慮物料需求計劃的時候，就沒有考慮到這個物料。所以，在生成采購訂單的時候，當然也不會把這個物料考慮進去。此時，就會引發(fā)另外一個問題。因為根據(jù)上面的需求描述，這個需求是按照銷售訂單、采購訂單、物料收貨單這個鏈條下去的。若沒有采購訂單的話，這個中間的鏈條就斷裂了。那么當用戶去查詢的時候，就會有這個疑問：為什么沒有這個物料呢？是否是采購忘記下采購訂單了呢？不少企業(yè)出于安全生產的需要，往往會備有安全庫存。當安全庫存沒有降低到采購點的話，則就不會發(fā)采購訂單。CIO在需求分析的時候，若沒有把這個應用情景描述出來，則這個需求分析仍然是不健全的。到時候程序開發(fā)人員設計的解決方案，仍然不能夠涵蓋企業(yè)所有的應用場景。

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

　　問題二：需求描述會給其它人帶來歧義嗎？
　　若CIO收集的需求描述，給不同的人看會有不同的結論，那么這個需求描述就不會有多大的實用價值?；蛘哒f，這些需求分析還是不要做的好。因為此時別人若按照你的需求描述去編寫解決方案，那么反而是在做無用功。

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

　　一是盡量從用戶的角度來考慮問題。當我們從用戶那邊把需求收集過來，然后需要利用自己的語言來對問題進行描述。若在這個描述的過程中，CIO站在自己的角度去思考，則往往會引起一些不必要的歧義。筆者認為，CIO在整理需求的時候，最好能夠站在用戶的角度去思考問題。同時，需求整理好后，最好能夠把自己整理的需求再讓用戶去確認一遍。讓他們審核一下，看看書面需求分析與他們的想法是否有出入。

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