在上世紀70 年代后期，系統分析師、系統設計師，和其他從事軟件工程的專業人員一直爭取希望能夠有一個國際公認的資格，類似會計師、律師、建筑師等專業的地位，但到了80 年代中期，這個議題已經不再存在，主要的原因是軟件工程內包含太多專業，除了軟件和硬件兩大類之外，還漸漸包括網絡，通信，數據庫等多方面。計算機從業人員開始體會及認識到本身的工作與會計師、律師、建筑師等專業資格可以在考核及認證后授予一定的權責，和建立一套環球衡量標準的模式是不一樣的。其實軟件工程比較像藝術家，大部份的軟件是模仿別人的成果加以個別的應用需求進行個性化的結果，把思維轉變成交付成果的一門專業。
過去數年常聽到一些軟件從業人員的投訴包括：“他們(客戶)基本上不知道自己的需求，怎么做他們都不滿意，功能不斷增加，如何能夠完成他們的系統建設?”“他們(客戶)上周說要這個功能，說要這個功能，為什么不全告訴我們，讓我們可以不用在開發過程中不斷更改!”一些類似的投訴只說明我們的軟件從業人員基本上沒有明白到范圍建設的重要性，而且未能在項目啟動前把項目范圍建立起來。
范圍與功能的分別
在“如何把握不存在的需求”一文中，已經說明范圍是有效管理需求變更的方法。有明確的項目范圍，我們才能夠學習及分析范圍內的作業流程，建立系統的功能需求，并在開發過程中當客戶要求變動的時候有效管理我們的工作范圍，才能夠有機會按照預算在指定的時間內完成項目的交付。
軟件開發項目從開始到，一直以來客戶都不能夠告訴我們需要哪些功能，他們只能告訴我們系統需要完成哪些目標。回顧“如何把握不存在的需求”一文中的第一個例子，20世紀70 年代的客戶需要把庫存管理進行自動化，收到的指示會像下例：“建立一套庫存管理系統取代目前的人工作業流程”。這一句指示是任務說明。系統分析員在接受這個任務后第一個工作是建立項目的Term of Reference (ToR)。系統分析員會進行初步調查，通過簡單的訪談，與庫存部門負責人明確理解他們工作的開始點和終結點，得出的結果可能像下例：“從貨品(包括原材料，半成品及制成品)進入倉庫開始，到貨品因應生產或銷售申領要求離開倉庫為止，其中包括貨品存入量的統計，存放位置記錄，總庫存量統計，申領數目，檢貨，提取貨品，準備出倉，后更新貨品存量統計等工作過程”。這是所謂的Term of Reference，也是我們所認識的項目范圍。
在用戶及管理層認同上述的ToR 后，這個項目的負責人便需要估計需要對多少人進行訪談，需要多久時間進行訪談，需要多少時間對訪談結果進行分析，多少時間建立項目需求，編寫需求說明書，需要多久進行系統設計，多少程序員及多少時間進行程序編寫，如何進行測試，編寫系統文檔，編寫用戶手冊，什么時候在倉庫安裝終端，如何連接主機，什么時候進行用戶培訓，如何讓系統取代目前的人工作業等等有關工作計劃及時間表。
在系統分析員完成訪談后，便需要依據訪談結果進行分析，理解什么時候知道有貨品進入倉庫，什么時候更新有關數據，如何更新，采用哪些表單，倉庫人員如何決定貨品應該存放在哪里，如何記錄有關信息，如何知道需要檢貨，什么時候進行數據更新，如何分別哪些貨品要去生產部門或者直接送到客戶指定地點等等信息。這些信息便成為系統在不同過程中所需的功能需求。
從上述的開發過程說明中可以體現功能需求并不是客戶或用戶提供，是系統分析員在理解目前的人工作業后分析出來的結果。
在系統移交到倉庫中運行前，倉庫中的工作人員需要對系統的操作進行學習及測試。要知道當時倉庫的工作人員并不是針對系統的功能進行測試，是對系統能否滿足他們的工作過程進行測試。基于這批工作人員對人于工作業的過程十分理解，如果系統未能提供一些他們操作過程中的日常工作，他們會要求技術人員對系統進行修改。這個過程讓我們誤會用戶是對功能需求進行測試，這個誤會一直到讓我們把系統開發的焦點錯誤地放在功能上，而不是系統的終交付上。而系統的終交付是否能夠滿足ToR 的要求是當時項目成敗的主要指標。
系統集成的范圍及需求
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: 有關發票內容自動轉發會計部門，建立有關應收賬款記錄。
