在需求分析中就可以避免的那些錯誤2

1、多考慮一下「哪些引數該取配置值」

乙個很久沒聯絡過我的合作夥伴在qq上緊急找我，因為我們很多年前開發的一套倉庫系統被他找到了新買家，但有個「小」問題需求我幫忙解決。原來系統裝好後，各項引數都按新公司配置好了，但列印出來的倉單頁首顯示的是其它公司的名稱。

好吧，我承認當年做報表時為了快速交貨，就將公司名直接寫死。原本這個值可以讀系統配置引數的。

2、再考慮是否存在「沒有票也可以上車」，「超過1.5m的小孩也不需要買全票」的場景？

在需求調研中，我們肯定可以獲取到業務的正常流程和規則是怎麼樣的，並記錄在需求分析文件裡。但實際業務中往往會出現很多特例，它們不符合業務規則但還得讓流程正常走下去。比如上車前要買票，但因為乘客特殊原因沒票也可以讓他先上車再補票。

又比如公司規定超過x噸的車不允許進閘。但如果系統這樣寫死，一些有特殊關係的車輛雖然超重但上級要求放它進閘時系統就解決不了了。到時it人員就要背鍋了。

以上都不是重點，重點是「需求調研時，除了要了解正常流程，一些潛規則也得打聽到並記錄下來。」

3、是否有「必須早到的人突然遲到了，或者經常晚到的突然早到了。」的情況。

虛擬乙個正常的業務場景：公司要求a員工拿鑰匙，每天先到公司開門。b員工每天在開門後把報紙放在c領導桌上。

如果程式設計時按順序寫死：a->b兩個人的業務流程，並且強制校驗它們的前後關係。那麼在 a比 b晚到的情況就執行不了，雖然發生的概率非常小，一旦發生了就會造成系統停滯。

在業務分析中，要思考一下是否會出現順序顛倒的場景產生，並和業務人員確認業務順序【萬一】顛倒時系統該怎麼處理？

案例：原方案：收到海關放行報文時，系統按照報文內的貨櫃號給在堆場的貨櫃解海關布控鎖。

實際業務中99.99%的箱子可以按上方案實現，但還是有0.01%箱子在收到海關放行報文後才進場。按以上方案無法解布控鎖，所以又重新修改方案和**：

新方案：1、收到海關放行報文時，按照報文內的箱號給在堆場的貨櫃解海關布控鎖。如果箱不在場時，先將報文寫入資料庫；

2、貨櫃進場時判斷資料庫中是否存有海關放行報文資料，如果有則箱落場後自動解除海關布控鎖，並將該箱的報文資料在資料庫中歸歷史。

3、報文寫入資料庫x天後，如果還未被使用，則自動歸歷史。