久久久91-久久久91精品国产一区二区-久久久91精品国产一区二区三区-久久久999国产精品-久久久999久久久精品

3　系統(tǒng)集成的應(yīng)用需求分析

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

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

3.1　應(yīng)用需求分析的一般方法

3.1.1　應(yīng)用需求分析的四個過程

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

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

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

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

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

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

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

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

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

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

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

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

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

在面向?qū)ο蠓治龅姆椒ㄖ?，通常使用Use Case來獲取軟件的需求。Use Case通過描述“系統(tǒng)”和“活動者”之間的交互來描述系統(tǒng)的行為。通過分解系統(tǒng)目標(biāo)，Use Case描述系統(tǒng)可見對象的交互行為。UseCase方法最主要的優(yōu)點在于它是用戶導(dǎo)向的，用戶可以根據(jù)自己所對應(yīng)的Use Case來不斷細(xì)化自己的需求。此外，使用Use Case還可以方便地得到系統(tǒng)功能測試的用例。

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

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

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

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

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

3.1.2　需求分析的兩個階段

在應(yīng)用需求分析的過程中，一般分為：第一，用戶需求分析、系統(tǒng)需求分析階段。第二，軟件需求分析階段。

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

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

URS描述了信息化集成系統(tǒng)軟件平臺所應(yīng)具有的外部行為，它包括最終交付的軟件必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計或?qū)崿F(xiàn)的約束條件（對開發(fā)人員在軟件產(chǎn)品設(shè)計和構(gòu)造上的限制）及質(zhì)量屬性。質(zhì)量屬性是通過多種角度對軟件產(chǎn)品的特點進行描述，從而反映交付系統(tǒng)的功能，這些要求對用戶和開發(fā)人員都極為重要。

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

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

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

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

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

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

作者簡介：

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

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