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

系統集成的基本目標是滿(mǎn)足最終用戶(hù)的需求，是按照用戶(hù)的需求，建立應用需求規格書(shū)，構建信息化集成系統。系統集成過(guò)程中，將用戶(hù)的實(shí)際需要變?yōu)閷π畔⒒上到y的功能要求，變?yōu)樾畔⒒上到y的應用需求規范是一件十分困難的事情。一個(gè)企業(yè)的信息化集成系統項目伊始，應用需求分析便成為最初的難點(diǎn)。對應用經(jīng)驗不足的系統集成商，或是對較大的系統集成項目，應用需求的把握可能始終伴隨著(zhù)工程全過(guò)程，直到項目的后期，還需回過(guò)頭來(lái)進(jìn)行需求分析。應用需求分析是信息化集成系統項目成敗的關(guān)鍵因素之一。

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

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

3.1.1　應用需求分析的四個(gè)過(guò)程

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

應用需求定義：應用需求就是從用戶(hù)的應用特點(diǎn)出發(fā)，依據企業(yè)總體規劃和目標，對系統進(jìn)行細化描述，就系統功能、性能、規格、行為、運行環(huán)境等提出要求。

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

從應用特點(diǎn)分析，系統需求可分為基本需求和特定需求（許多大型信息化集成系統項目中，稱(chēng)為用戶(hù)通用要求與專(zhuān)用要求）。在特定需求中又可細分為必需的特定需求和非必需的特定需求。一般來(lái)說(shuō)，特定需求往往決定系統的二次開(kāi)發(fā)。

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

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

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

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

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

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

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

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

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

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

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

針對上面談到的那些典型需求風(fēng)險，通?？煽紤]從以下3個(gè)方面實(shí)施風(fēng)險控制：

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

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

對需求理解差異的控制：由于業(yè)務(wù)人員和技術(shù)人員在專(zhuān)業(yè)背景上的不同造成對需求理解上存在差異，是導致項目返工和實(shí)施效果不理想的重要因素。要盡可能減小差異量，就需要雙方對需求的溝通要盡可能充分。特別是開(kāi)發(fā)人員，在進(jìn)行需求調研時(shí)要注意多主動(dòng)提問(wèn)題，對不清楚的地方一定要反復確認，切不可含糊過(guò)關(guān)。此外，針對不同業(yè)務(wù)領(lǐng)域，可指定業(yè)務(wù)部門(mén)有經(jīng)驗的代表全程參與項目建設過(guò)程，隨時(shí)進(jìn)行需求溝通，及時(shí)消除在需求上的誤解?！　?/p>

3.1.2　需求分析的兩個(gè)階段

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

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

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

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

URS必須滿(mǎn)足以下要求：（1）完整性。每一項需求都必須將所要實(shí)現的功能描述清楚，以使開(kāi)發(fā)人員能設計和實(shí)現這些功能。（2）正確性。每一項需求都必須準確地陳述其要開(kāi)發(fā)的功能。這里只有用戶(hù)代表才能確定用戶(hù)需求的正確性。（3）可行性。每一項需求都必須是在已知系統和環(huán)境的能力和限制范圍內可以實(shí)施的。（4）必要性。每一項需求都應把客戶(hù)真正所需要的和最終系統所需遵從的標準記錄下來(lái)?！氨匾浴币部梢岳斫鉃槊宽椥枨蠖际怯脕?lái)授權編寫(xiě)文檔的“根源”。要使每項需求都能回溯至某項客戶(hù)的輸入，如使用實(shí)例或別的來(lái)源。（5）一致性。對所有需求說(shuō)明都只能有一個(gè)明確統一的解釋。（6）劃分優(yōu)先級。給每項需求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級以指明它在特定產(chǎn)品中所占的分量。（7）可驗證性。檢查一下每項需求是否能通過(guò)設計測試用例或其它的驗證方法，如用演示、檢測等來(lái)確定產(chǎn)品是否確實(shí)按需求實(shí)現。

URS初始輸入來(lái)自業(yè)務(wù)人員、用戶(hù)，側重于把系統要解決的業(yè)務(wù)邏輯、要實(shí)現的功能描述清楚，更宏觀(guān)。在現代工業(yè)的系統集成項目中，URS更強調軟件開(kāi)發(fā)人員的參與，已經(jīng)有了許多行之有效的編制URS的軟件，甚至使用專(zhuān)門(mén)的URS APP軟件來(lái)生成信息化集成系統的用戶(hù)需求規格書(shū)。

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

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

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

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

作者簡(jiǎn)介：

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

摘自《自動(dòng)化博覽》2017年3月刊