日本在线www-日本在线播放一区-日本在线不卡免费视频一区-日本在线不卡视频-成人影院久久久久久影院-成人影院一区二区三区

3　系統集成的應用需求分析

系統集成的基本目標是滿足最終用戶的需求，是按照用戶的需求，建立應用需求規格書，構建信息化集成系統。系統集成過程中，將用戶的實際需要變為對信息化集成系統的功能要求，變為信息化集成系統的應用需求規范是一件十分困難的事情。一個企業的信息化集成系統項目伊始，應用需求分析便成為最初的難點。對應用經驗不足的系統集成商，或是對較大的系統集成項目，應用需求的把握可能始終伴隨著工程全過程，直到項目的后期，還需回過頭來進行需求分析。應用需求分析是信息化集成系統項目成敗的關鍵因素之一。

應用系統開發實施過程中，由于從事的職業和技術的局限，用戶很難準確地把應用系統的需求表達給系統開發人員；由于業務知識的局限，開發人員也很難準確獲取用戶真實的應用需求，因此，需求信息的不對稱和需求描述的錯位，往往容易引起系統設計的缺陷，從而導致應用系統不理想甚至系統失敗。需求調研和分析是信息化集成系統建設的第一步，也是非常關鍵的一步。本講對應用需求的分析面向工業信息系化集成項目的領導者、管理者、系統設計師、軟件架構師、軟件開發團隊負責人和項目相關的工程技術人員，提供信息化集成系統應用需求分析的總體技術觀點。需求分析的技術細節特別是軟件需求工程的技術細節，諸如，建模、軟件需求分析的具體方法等應去參考專著和專門的技術文件。

3.1　應用需求分析的一般方法

3.1.1　應用需求分析的四個過程

大型工業企業構建其信息化集成系統的第一步是進行系統的規劃，此項工作一般由一些著名的做信息化規劃的大公司來完成。應用需求的總體要求包含在這些信息化規劃之中。具體應用需求分析包括四個過程：

應用需求定義：應用需求就是從用戶的應用特點出發，依據企業總體規劃和目標，對系統進行細化描述，就系統功能、性能、規格、行為、運行環境等提出要求。

從系統特點分析，應用需求主要分為功能需求和性能需求；功能需求主要描述系統要完成的目標，系統能夠解決的問題，幫助用戶完成什么工作；性能需求主要描述系統性能指標上要達到的要求，主要包括系統可靠性，系統響應性指標（響應時間、平均無故障工作時間、故障后自動恢復時間等）軟硬件環境的限制指標和其他的設計約束等。

從應用特點分析，系統需求可分為基本需求和特定需求（許多大型信息化集成系統項目中，稱為用戶通用要求與專用要求）。在特定需求中又可細分為必需的特定需求和非必需的特定需求。一般來說，特定需求往往決定系統的二次開發。

在系統集成工程中，一種較為成功的方法是開發出功能點表。功能點表詳細列出了功能要求及其實現的場景，系統集成師與軟件開發人員將這些功能分為現有軟件平臺可以實現的功能和需要在開放平臺上開發的功能。進而言之，應用需求分析的核心和落腳點是軟件需求分析，最終要將系統的功能需求轉化為軟件架構和編程的需求。

應用需求調研：需求調研的過程是獲取用戶需求的過程。首先要調查清楚系統應用部門的所有用戶類型以及潛在的類型，根據他們的要求來確定系統的整體目標和系統的工作范圍，然后對用戶進行訪談和調研，交流的方式：專題座談會、單獨面談、電話交流、電子郵件、小組討論、模擬演示等不同形式。交流一定要有記錄，交流的結果進行分類，以便于后續的分析活動。

需求調研通常涉及三個問題：（1）如何確定調研人員；（2）如何確定被調研對象；（3）采用何種調研方法。需求調研人員的組成應以互補為原則，至少要由三類人員組成：技術人員、業務專家和管理者。調研范圍包括關鍵域和關鍵活動。關鍵活動又由關鍵流程和關鍵點構成。找到關鍵域，明確關鍵流程的關鍵點，對于需求調研至關重要，需要專家或咨詢顧問介入。而能否把握這一時機并找準需求提煉的關鍵點，是考驗需求調研人員的重要方面。優秀的需求調研人員不僅能認識問題之所在，還能藉此獲取足夠多的知識，最后成為這些問題領域的專家。

對于用戶提出的每個需求都要弄清“為什么”，并判斷用戶提出的需求是否有立足的理由；將那種以“如何實現”的表述方式轉換為“實現什么”的方式，因為需求分析階段關注的目標是“做什么”，而不是“怎么做”；分析由用戶需求衍生出的隱含需求（有可能是實現用戶需求的前提條件）。

用戶需求調研涉及到用戶和系統分析人員雙方，為了使用戶需求調研工作順利進行，必須事先制定一個調研計劃。調研計劃中包含調研計劃基本信息、時間安排、調研內容、接待部門和人員、調研成果等5個方面的信息。具體調研方法較多經常采取的調查方法主要有表格調查法、座談調查法、查閱資料法和現場觀察法4種。

應用需求分析：應用需求分析是信息化集成系統系統集成中非常重要的內容。應用系統需求分析應包括應用需求調研、模擬和分析需求、需求描述、需求認可、需求演進五個層次。應用需求分析是信息化系統軟件工程的核心，貫穿于系統整個生命周期。

應用需求分析和模擬又包含三個層次的工作：需求定義、需求建模、需求模擬。需求定義是對經調研獲取的需求進行初步整理，抽取其中基本需求和關鍵需求予以界定，并為需求建模提供必要的需求元素。需求建模是把抽象的需求通過概念、符號、數學模型及邏輯結構表現出來。表現形式有自然語言、半形式化（如圖、表、結構化英語等）和形式化表示等三種。

在很多情況下，分析用戶需求和獲取用戶需求往往是并行的，通過建立需求模型的方式來描述用戶的需求，為系統客戶、用戶、開發方等不同參與方提供一個交流的平臺和遵循的依據。這些模型是對需求的抽象，以可視化的方式提供一個易于溝通的渠道。分析用戶需求的過程實際上也是一個建立模型的過程。

用于系統需求建模的方法有很多種，按照軟件工程的方法，最常用的包括數據流圖（DFD）、實體關系圖（ERD）和用例圖（Use Case）三種方式。

在面向對象分析的方法中，通常使用Use Case來獲取軟件的需求。Use Case通過描述“系統”和“活動者”之間的交互來描述系統的行為。通過分解系統目標，Use Case描述系統可見對象的交互行為。UseCase方法最主要的優點在于它是用戶導向的，用戶可以根據自己所對應的Use Case來不斷細化自己的需求。此外，使用Use Case還可以方便地得到系統功能測試的用例。

需求風險及控制：既然應用需求對構建信息化集成系統成敗起到如此關鍵之作用，對應用需求風險的控制就變得尤為重要。在應用軟件開發過程中，由于軟件需求本身的隱含性、用戶與開發者之間的溝通障礙，以及需求隨著時間、用戶的變化而變更等原因，可能使需求分析偏離實際需求而最終導致軟件開發的失敗，這種可能性稱為需求風險。總結企業信息化集成項目實施過程中遇到的需求問題，大致可將需求風險歸納為如下幾種類型：（1）需求頻繁變更，項目范圍被隨意擴大，導致項目的成本費用增加、開發周期延長、開發質量和工作效率下降；（2）缺乏明確的部門或人來真正對需求負責，造成業務需求缺乏規劃，需求的片面性和矛盾性比較突出，需求質量受到需求提出者個人能力的影響；（3）受專業領域所限，技術人員和業務人員在溝通上存在著一些障礙。（4）開發人員將興趣點更多放在技術產品和程序編碼上，對需求分析工作的關注度和精力投入不足，造成了實際系統與用戶期望不符；（5）業務人員對項目初期的需求確認缺乏足夠重視，往往等到系統上線后才提出各種問題，嚴重影響了項目的實施效果。

針對上面談到的那些典型需求風險，通常可考慮從以下3個方面實施風險控制：

對需求變更的控制：通常會采取以下幾種措施來實施需求變更控制；（1）建立項目需求變更管理流程，由開發人員和需求人員共同組成需求評審組，對變更需求進行嚴格評審；（2）需求確定后，要建立明確的需求基線，并敦促業務人員要對需求確認這個環節的工作給予高度重視，以正式文件形式發送至業務部門簽署確認意見；（3）與業務人員一起對變更的需求建立優先級，采取分批方式逐步實現，并注意確保核心模塊的相對穩定；

對需求質量的控制：對需求質量控制的關鍵是要保證找到理想的需求調研對象。需求調研對象的角色、個人經驗和能力將直接影響到需求的全面性、有效性和合理性。針對不同類型的調研對象，應注意采取適合的訪談方式，并在提問時給予必要的引導。開發人員可以根據以往項目積累的經驗，提出一個比較成熟的原型需求，交給業務人員進行確認。

對需求理解差異的控制：由于業務人員和技術人員在專業背景上的不同造成對需求理解上存在差異，是導致項目返工和實施效果不理想的重要因素。要盡可能減小差異量，就需要雙方對需求的溝通要盡可能充分。特別是開發人員，在進行需求調研時要注意多主動提問題，對不清楚的地方一定要反復確認，切不可含糊過關。此外，針對不同業務領域，可指定業務部門有經驗的代表全程參與項目建設過程，隨時進行需求溝通，及時消除在需求上的誤解。　　

3.1.2　需求分析的兩個階段

在應用需求分析的過程中，一般分為：第一，用戶需求分析、系統需求分析階段。第二，軟件需求分析階段。

從用戶角度看，第一階段是他們的需求按照專業領域的要求來描述，似乎并不需要對軟件開發需求負責。從軟件開發的視角，第一階段的需求應該完整、一致，明確無誤，最好是穩定的不發生重大變化的。第二階段的應用需求分析看似由軟件開發人員來進行，但必須要應用系統設計人員與工程實施者從始至終參與。實質上，兩個階段的工作任務是一個整體，應以系統設計團隊與軟件開發團隊密切合作為根本。最終制定出軟件需求規格說明書（Software Requirements Specification，SRS）作為應用需求分析的成果。

（1）用戶需求分析、系統需求分析階段：此階段包括業務需求分析，用戶需求分析及系統需求分析。應由用戶項目負責人與系統集成師為主制定用戶需求規格書URS (User Requirement Specification) 。這是需求調研和分析的直接成果。好的需求規格書，其需求層次清晰，語言專業且精練，基本需求描述完整。特定需求既有現實性又有前瞻性，流程和結構定義準確，有可操作性等。需求規格說明書的主要服務對象可來自于用戶、系統分析員、軟件需求分析員、軟件開發人員、程序員、測試員和項目管理人員等，但歸根結底還是要尊重用戶發展戰略和機構運行策略所必需的現實和潛在的期望。如何及時獲取和適應需求變化，并適時修改和整理系統需求文檔而保持系統的進化，是系統成功的又一關鍵環節。可以說，基于需求演進項目管理效率直接決定系統能否支持用戶的持續變革。

URS描述了信息化集成系統軟件平臺所應具有的外部行為，它包括最終交付的軟件必須遵從的標準、規范和合約；外部界面的具體細節；性能要求；設計或實現的約束條件（對開發人員在軟件產品設計和構造上的限制）及質量屬性。質量屬性是通過多種角度對軟件產品的特點進行描述，從而反映交付系統的功能，這些要求對用戶和開發人員都極為重要。

URS必須滿足以下要求：（1）完整性。每一項需求都必須將所要實現的功能描述清楚，以使開發人員能設計和實現這些功能。（2）正確性。每一項需求都必須準確地陳述其要開發的功能。這里只有用戶代表才能確定用戶需求的正確性。（3）可行性。每一項需求都必須是在已知系統和環境的能力和限制范圍內可以實施的。（4）必要性。每一項需求都應把客戶真正所需要的和最終系統所需遵從的標準記錄下來。“必要性”也可以理解為每項需求都是用來授權編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如使用實例或別的來源。（5）一致性。對所有需求說明都只能有一個明確統一的解釋。（6）劃分優先級。給每項需求、特性或使用實例分配一個實施優先級以指明它在特定產品中所占的分量。（7）可驗證性。檢查一下每項需求是否能通過設計測試用例或其它的驗證方法，如用演示、檢測等來確定產品是否確實按需求實現。

URS初始輸入來自業務人員、用戶，側重于把系統要解決的業務邏輯、要實現的功能描述清楚，更宏觀。在現代工業的系統集成項目中，URS更強調軟件開發人員的參與，已經有了許多行之有效的編制URS的軟件，甚至使用專門的URS APP軟件來生成信息化集成系統的用戶需求規格書。

（2）軟件需求分析階段：在URS的基礎上，進入軟件需求分析。在確定了系統的總體結構方案基礎上，確定應用程序的結構、系統開發環境和系統的功能模塊。從用戶應用角度來看，可把應用程序系統的組成部分分成數據存儲層、業務處理層和界面表示層等3個層次，而應用程序結構可歸納為：集中式應用程序結構、單用戶應用程序結構、多層服務器應用程序結構、瀏覽器／服務器應用程序結構、客戶機／服務器應用程序結構等5種類型。一個具體的軟件開發項目，應該將應用程序的結構首先確立。

在基本功能塊框架確定后，應由軟件團隊為主，進行軟件需求分析工作，主要是完成軟件需求規格書SRS（Software Requirements Specification）的制定。與URS相似，SRS也獨具特點：（1）完整性。需求的完備性表達，不能遺漏任何必要的需求信息。注重用戶的任務而不是系統的功能將有助于避免不完整性。（2）一致性。一致性是指與其它軟件需求或高層（系統，業務）需求不相矛盾。在開發前必須解決所有需求間的不一致部分。（3）可修改性。在必要時或為維護每一需求變更歷史記錄時，應該修訂SRS。這就要求每項需求要獨立標出，并與別的需求區別開來，從而無二義性。每項需求只應在SRS中出現一次，這樣更改時易于保持一致性。（4）可跟蹤性。應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好（fine-grained）的方式編寫并單獨標明，而不是大段的敘述。

SRS與URS不同點是：（1）面向設計、開發人員。（2）側重于把系統的約束、輸入、輸出和處理過程定義清楚并更具體。（3）是從業務規則講起的，偏向于軟件的概要設計，是從開發、測試的角度去說明產品功能，包含原型界面、業務接口、活動圖等。

關于軟件SRS，國際標準中推薦有SRS的模板供參考，重要的是理解其中的含意，這是軟件需求分析階段最重要的工作。

作者簡介：

魏曉東，1967年畢業于天津大學精儀系。1984~1991年任安徽工業大學自動化系副教授。1991年出版《分散型控制系統》（ 上海科技文獻出版社） 。2000~2012年任北京和利時系統工程公司副總工、事業部總設計師，北京地鐵13號線、深圳地鐵一期工程、廣州地鐵3號線綜合監控系統工程技術總負責人。2006、2010年出版《城市軌道交通自動化系統與技術》初版與第二版（電自工業出版社）；2010年主編國家標準《城市軌道交通綜合監控系統工程設計規范》（GB50636-2010）《城市軌道交通綜合監控系統施工與質量驗收規范》（GB/T50732-2011）；2010年主編關于兩化融合的國家標準《工業企業信息化集成系統規范》（GB/T26335-2010）。2013年至今任清華同方數字城市工程中心技術專家，住建部城市軌道交通標注技術網Eu委員會委員，全國自動化系統與集成標準技術委員會委員。

摘自《自動化博覽》2017年3月刊