SOW‐7: 自動通知業(yè)務點有關訂單發(fā)貨日期。

　　SOW‐8: 有關發(fā)票內容自動轉發(fā)會計部門，建立有關應收賬款記錄。

　　SOW 并不是我們所說的系統(tǒng)功能，是在項目完結后這個系統(tǒng)所應該提供的最終目的。以上的SOW 說明了這個項目的范圍，包括的有關部門及現有系統(tǒng)的連接。在客戶確認后每一個SOW 將當作一個ToR處理，這個ToR 便成為整個系統(tǒng)建設項目中的一個子項目(也是子項目名稱的起源)。如何才知道我們建立的SOW 已經包含整個系統(tǒng)的各個部門，如何保證這個范圍能夠有效地提供一套“訂單管理”的系統(tǒng)，這需要項目負責人對行業(yè)有一定的理解，同時為保證開發(fā)過程中能夠控制范圍的變動，在有關文檔中明確說明SOW 所包含或不包含那些工作。利用“包含(Inclusive)”和“不包含(Exclusive)”的說明來牢牢地建立一個固定項目范圍。

　　在項目規(guī)劃完成后，系統(tǒng)分析師便按照被分派的SOW 采用ToR 的調查方式進行深入調查，對有關工作進行訪談，理解有關SOW 的工作流程后對有關流程進行分析，并找尋初步的解決方案。如何利用科技取代電話咨詢庫存量，利用科技取代傳真把訂單從業(yè)務部門傳送回銷售部門，或取代傳真送貨通知單到運輸部門，取代內部文件傳送發(fā)票副本到會計部門等等工作，什么時候需要進行數據收集，需要進行數據更新，需要打印發(fā)票或其它有關報告等工作便成為項目的功能需求。

　　如果在開發(fā)過程中，用戶認為需要貨品在運送完畢后，收貨單應該自動確認有關應收賬款的作業(yè)流程，或者需要增加萬一退貨后的訂單處理操作流程時，我們便可以依據原SOW 來控制項目的范圍變動，因為這兩項操作流程并沒有在項目的SOW 中說明。如果用戶認為一定需要增加這兩個操作流程，那么項目的范圍會變動，帶出額外的工作量，額外的開發(fā)時間，額外的投資預算，修正系統(tǒng)的架構，增加軟件模塊，追加人力資源等等因應的后果。有能力的項目負責人會盡量說服客戶把有關工作在目前的系統(tǒng)建設完成后才進行處理，避免延誤項目的進度和交付日期。

　　這個系統(tǒng)集成的項目再一次說明如何從項目范圍中建立有關功能需求。建立功能需求是軟件從業(yè)人員的責任，不是客戶或用戶能夠提供的內容。在完成人工操作過程分析訂立系統(tǒng)的功能需求后，更要進一步考慮如何讓科技提升企業(yè)的運營效率。也許在設計過程中發(fā)現當時的貨品運送流程是從倉庫直接送到銷售部門，再由銷售部門安排貨品連同發(fā)票一起送到客戶的指定地點，設計師可能考慮是否可以直接從倉庫把貨品運送到客戶指定地點，銷售部門另外把有關發(fā)票直接送交客戶?這個改變會為企業(yè)帶來多大效率改善?有了確實的構思后便需要說服用戶這個系統(tǒng)如何能夠更有效地完成有關貨品運送的過程，要說服用戶這些功能可以提升貨品運送的效率和客戶滿意度，讓銷售部門和運輸部門可以體會未來的工作流程將有所改變。決定最終解決方案及用戶認可后依據分析師的建議建立有關系統(tǒng)的功能，交由系統(tǒng)設計師對有關功能進行模塊組合及邏輯設計。到這里，我們可以清楚知道系統(tǒng)建設不是依據客戶的需求而建設，是依據如何達到項目最終目的和項目的最終交付