20世紀70 年代的項目多以部門單獨運營為主，自動化的目的是提升部門本身的運營效率進行系統建設。到80 年代，企業高層開始體會企業中的數據分散在不同的部門或子公司的部門中。哪些數據是最新的?哪些是最準確的?應該采用哪個部門的數據做決定呢?如何整合這些數據，如何獲得即時的數據，如何利用當時的區際網絡(AreaNetwork)，客戶/服務端(Client/Server)，遙程存取(Remote‐Access)數據庫(Data Base)等科技來更有效提升企業的運營效率呢?這些問題提供軟件開發項目進行系統集成及數據分享的工作，最終的目的還是環繞原來自動化提升企業(不單是70 年代提升部門)的整體運營效率為主要目標。
這個時候，簡單的ToR 已經不能夠說明項目的范圍，但可以采用多個ToR 來加以說明。工作說明(Statement of Work)在這個時候誕生，開始取代ToR 成為項目范圍的主要工具。一個項目可能有多個Statement of Work(SOW)才能夠有效說明項目包含的范圍。例如要建立一個 “訂單管理系統(Order Processing System)”的時候，這個系統可能包括銷售部門，庫存管理部門，會計部門，運輸部門，生產部門等，這些部門也可能分布在不同的地區。
項目負責人首要是建立這個“訂單管理系統”的范圍，保證能夠提供訂單管理的的全部工作，所以會首先進行初步調查，理解一張訂單從不同業務點如何把訂單傳送回銷售部門，銷售部門如何把訂單信息轉進倉庫，如何結合現有庫存管理系統，如何通知會計部門有關銷售，如何通知運輸部門需要送貨，或者如何通知生產部門需要進行生產等內容。在與個別部門負責人完成初步訪談后會，理解訂單在各個部門的進入點和輸出點后才建立這個項目的工作說明(SOWs)如下：
SOW‐1: 連接業務點各終端到銷售系統，建立當天的銷售記錄。
SOW‐2: 連接銷售系統與庫存管理系統，容許銷售部門查詢倉庫管理系統中有關貨品庫存量。
SOW‐3: 容許銷售部門在庫存系統中預訂貨品數量以便運送到客戶指定地點。
SOW‐4: 容許銷售部門指示庫存工作人員進行檢貨，并通知運輸部門有關訂單的運送要求。
SOW‐5: 在銷售部門計算有關訂單的總金額，運送費及保險費用，并生成發票送交客戶。
SOW‐6: 自動更新倉庫貨品儲存量，如有關貨品低于最低數時，建立貨品生產通知單并傳送到生產規劃部。
SOW‐7: 自動通知業務點有關訂單發貨日期。
SOW‐8: 有關發票內容自動轉發會計部門，建立有關應收賬款記錄。
SOW 并不是我們所說的系統功能，是在項目完結后這個系統所應該提供的最終目的。以上的SOW 說明了這個項目的范圍，包括的有關部門及現有系統的連接。在客戶確認后每一個SOW 將當作一個ToR處理，這個ToR 便成為整個系統建設項目中的一個子項目(也是子項目名稱的起源)。如何才知道我們建立的SOW 已經包含整個系統的各個部門，如何保證這個范圍能夠有效地提供一套“訂單管理”的系統，這需要項目負責人對行業有一定的理解，同時為保證開發過程中能夠控制范圍的變動，在有關文檔中明確說明SOW 所包含或不包含那些工作。利用“包含(Inclusive)”和“不包含(Exclusive)”的說明來牢牢地建立一個固定項目范圍。
在項目規劃完成后，系統分析師便按照被分派的SOW 采用ToR 的調查方式進行深入調查，對有關工作進行訪談，理解有關SOW 的工作流程后對有關流程進行分析，并找尋初步的解決方案。如何利用科技取代電話咨詢庫存量，利用科技取代傳真把訂單從業務部門傳送回銷售部門，或取代傳真送貨通知單到運輸部門，取代內部文件傳送發票副本到會計部門等等工作，什么時候需要進行數據收集，需要進行數據更新，需要打印發票或其它有關報告等工作便成為項目的功能需求。
文章來源于領測軟件測試網 http://www.kjueaiud.com/