IT伯伯的部落格

前幾篇我向大家分享了系統分析師必須具備的軟實力其中的「觀察」、「商業思維」及「聆聽」，在講述下一個主題之前，想先跟大家分享一些案例。此篇為第一個案例！

專案背景：P公司的貨品在台灣由L公司負責物流服務，P公司的產品品牌眾多，且貨量非常大，佔L公司營收比重為10～15%

專案需求：L公司在處理收貨及加工商品時，希望由系統計算目的存放位置

專案成員：

此專案我的角色為PM，SA為輔，主SA是X先生

分享內容：

在瞭解完系統需求之後，X先生開始撰寫系統規格書，X先生係L公司年資較深的SA，而我僅剛到職2個月，所以主管指派X先生協助我。以下內容為X先生撰寫的規格書示意：

1. 取出商品的儲區，放入變數@putawayzone；儲存型態放入變數@putawaytype
2. 取出該儲區的品牌別及儲位是單一棧板還是雙棧板，放入變數@brand及@bintype
3. 先判斷若@bintype=‘double’且@putawaytype=‘D’，則執行以下程序（略）
4. 若@bintype<>’double’且@putawaytype=‘D’，則執行以下程序（略）

⋯⋯⋯｛略}⋯⋯⋯

看完後，不知道大家有什麼想法，但這種寫法非常常見，因為通常SA都是PG升上來的，所以這種版本是通例。先說明我沒有批評之意！

但正確的寫法應該要以商業思維去撰寫，而且務必保持KISS（Keep It Simple and Stupid）原則去寫，否則就是搶了SD/PG的工作了！

所以我改寫了一下：

1. 自商品主檔取出該產品的預設入庫儲區及儲存型態
2. 取得該預設入庫儲區的所屬品牌，並將對應的所有儲位其儲位屬性一併取得
3. 若該商品的儲存型態為’D’，則

     3.1先執行以下儲位型態為double的區段，若取不到資料則繼續執行3.2，否則取到的值即為目的

     3.2執行儲位型態不為double的區段，若取到值則為目的，否則回傳空白

⋯⋯⋯｛略｝⋯⋯⋯

上面我改寫後的版本是否較容易閱讀且利於溝通呢？

［2021/7/1 13:42］格式調整，將重點標註清楚增加可閱讀性