80年代后期至90年代中期的時間進行自動化過程。
80年代的項目范圍與需求
到上世紀80年代中后期，國外企業(yè)的自動化過程已經(jīng)接近尾聲，企業(yè)開始整合部門的計算機系統(tǒng)，加上個人電腦開始取代終端，項目多數(shù)包括跨部門或跨地區(qū)的系統(tǒng)集成、綜合數(shù)據(jù)庫應用、遠程計算(Remote Access)、網(wǎng)絡連接等為項目主體。在這種情況下，傳統(tǒng)的ToR已經(jīng)不能夠明確說明項目屬于哪個部門，從哪里開始，如何才是項目完結(jié)。ToR已經(jīng)不能夠有效地界定項目的范圍，所以，我們利用多個工作描述來說明，成為我們知道的工作說明“Statement of Works (SOW)”，其中包括項目開發(fā)過程中需要處理(inclusive)的工作說明和開發(fā)過程中不需要(NOT-inclusive)處理的工作說明，整合這些SOWs 后成為我們今天所認識的項目范圍，利用工作說明以明確的語句來說明項目中包含的每一個工作內(nèi)容。例如，在一個項目范圍中包括的工作說明可能是:“連接A市及B市兩地辦公室的主機，通過A市數(shù)據(jù)中心的中央貨品庫存數(shù)據(jù)庫，為A市工場和B市銷售中心提供即時貨品存量查詢及貨品預訂功能”。
這些工作說明便成為這個工程需要提交的最終成果。利用項目范圍中的SOW替代ToR，一個項目可以容許多個SOW來描述系統(tǒng)建設(shè)的內(nèi)容，所有的SOW描述的建設(shè)內(nèi)容都包含在這個項目的范圍中。但實際上每一個SOW的結(jié)果如何實現(xiàn)，還是需要技術(shù)人員透過調(diào)查和進行分析后才能夠清楚具體的操作該如何實現(xiàn)。每一個SOW的具體操作過程都成為這個SOW的功能需求。整合全部SOW的個別操作過程，才是項目的最終功能需求。
簡明的說，每一個SOW都是一個小范圍，它本身也不是一個需求。我們還是需要通過理解SOW的內(nèi)容才能夠把握這個SOW的需求。每一個SOW可以成為一個獨立的項目，“子項目”的名稱也是在這個時候誕生。
從上述的歷程中可以看到，用戶或客戶告訴我們的永遠都不是需求，是客戶或用戶希望在最后交付物中看到的部分成果，永遠不會完整，只是客戶或用戶的部分期盼、愿景和目標。如果把這些期盼、愿景和目標當作了需求，那么我們永遠不能在項目初期建立滿足用戶對交付物的期盼。需求從來不是用戶或客戶提供，需求是技術(shù)人員依據(jù)范圍中需要實施的工作過程進行分析后尋找出來可以提交項目最終交付物的結(jié)果，然后才能夠把這些需求轉(zhuǎn)變成一個軟件工程，在項目指定的范圍中利用科技達到用戶的最終目的?！?/P>
系統(tǒng)集成項目在PMBOK論述的范圍管理仍然有效，但在軟件工程中能否包含全部SOW是影響范圍變動的主要因素，遺漏了一個SOW便會帶來范圍變動，所以當時的軟件工程多以SOW為主，需要客戶方確認，只要客戶確認SOW后，任何不包括在SOW中的功能便成為范圍變動，也是PMBOK中范圍變動管理的主要意義。改變范圍便需要改變項目基線，增加工作量和項目成本，延長項目工期。我國的軟件產(chǎn)業(yè)發(fā)展從2O世紀90年代中期到本世紀初期才開始進行系統(tǒng)集成的過程。
自動化到信息化的年代
IT在上世紀70、80年代的項目是流程自動化與系統(tǒng)集成年代，基本上是先確認范圍后才開始把握功能需求，大部份項目所采用的開發(fā)體系也是依據(jù)這個構(gòu)思對軟件開發(fā)進行管理。但到了90年代進入信息化年代，范圍的意識開始模糊，范圍開始被誤解成為需求，最主要的原因是技術(shù)人員仍然采用過去流程自動化的開發(fā)思維，希望客戶能夠明確說明范圍，但在范圍建立的過程中，每當客戶提出“我需要這個系統(tǒng)能夠提供 …… ”，技術(shù)人員便把客戶的說明演繹成為系統(tǒng)需求。
故此從90年代中期開始到現(xiàn)在，很多軟件工程師對需求的定義非常模糊，系統(tǒng)需求與功能需求把握不