【原】汽車行業(yè)業(yè)務(wù)需求分析的解決方案

Donald當(dāng)勞 2021-11-20

展開全文

1、汽車行業(yè)的復(fù)雜性

汽車行業(yè)的軟件開發(fā)有別于傳統(tǒng)互聯(lián)網(wǎng)行業(yè)的軟件開發(fā)，其更傾向于一個系統(tǒng)工程。因為你除了要關(guān)心軟件系統(tǒng)以外，同時也要兼顧不同零部件之間的協(xié)作，以及ECU的算力問題。所以，并不能簡單地通過傳統(tǒng)的瀑布、敏捷等開發(fā)方法直接套用在汽車行業(yè)當(dāng)中。

基于汽車行業(yè)的復(fù)雜度，行業(yè)的軟件成熟度通過ASPICE進行評估。ASPICE通過V模型來體現(xiàn)其設(shè)計的生命周期，并將相關(guān)的生命周期區(qū)分成SYS系統(tǒng)V模型，SWC軟件V模型兩個主要層面來了解汽車。同時硬件開發(fā)、線束、布線等都有其相應(yīng)的V模型進行表現(xiàn)。

ASPICE對整車開發(fā)定義了多套V模型，包括系統(tǒng)分析V模型、軟件開發(fā)V模型、硬件開發(fā)等多種V模型。

汽車電子電器架構(gòu)設(shè)計從傳統(tǒng)的分布式結(jié)構(gòu)逐步發(fā)展，向領(lǐng)域驅(qū)動和中心化的方向推進，其目的就是簡化電子電器的線束的復(fù)雜度，并且能夠通過統(tǒng)一的方式使用和調(diào)度不同Zone區(qū)域節(jié)點的功能。

OMG組織發(fā)布的系統(tǒng)建模語言SysML是一種通用圖形建模語言，通過需求、分析、設(shè)計、驗證等角度來定義復(fù)雜系統(tǒng)，實現(xiàn)對包括硬件、軟件、信息、人員、程序和設(shè)施等的定義。該語言提供了大量UML擴展的圖形，針對系統(tǒng)建模當(dāng)中的系統(tǒng)需求，行為，結(jié)構(gòu)和參數(shù)的語義等信息，并可以用于與其他工程分析模型集成進行。

SysML針對相關(guān)的行業(yè)定義了一些特有的圖形進行描述，專業(yè)的汽車設(shè)計軟件PREEvision，是一個可以支持整車電子電器開發(fā)設(shè)計以及仿真的軟件，PREEvision為汽車EEA電子電器開發(fā)的各個階段提供了不同的圖形的支持。

但是，即使是有一定的技術(shù)基礎(chǔ)，很多時候遇到具體業(yè)務(wù)場景實施時，依然會有各種各樣的問題。一方面各種方法論無法通用地解決所有問題；另外一方面，汽車行業(yè)從業(yè)人員需要的技能比較多，要能夠透徹看清楚各個環(huán)節(jié)，需要大量跨領(lǐng)域的知識。大多從業(yè)人員自身的技能依然維持在傳統(tǒng)的模式上，行業(yè)局限性比較大，軟件及架構(gòu)等技能也相對有限。

2、使用UML驅(qū)動汽車行業(yè)需求分析的意義

UML是一種通用的建模語言，其作用貫穿整個軟件系統(tǒng)的生命周期。SysML是UML的一個子集，它繼承和擴展了UML基礎(chǔ)的各種能力和模型。

UML是一種用于對軟件密集型系統(tǒng)進行可視化、詳述、構(gòu)造和文檔化的建模語言，主要適用于分析與設(shè)計階段的系統(tǒng)建模。UML最主要的特點是表達能力豐富。UML從各種OOA&D方法中吸取了大量的概念，對這些概念的語義、圖形表示法和使用規(guī)則作了完整而詳細的定義?？梢哉f，UML對系統(tǒng)模型的表達能力超出了以往任何一種OOA&D方法。當(dāng)然，它的復(fù)雜性也超出了以往任何一種方法。

UML的問世引起了計算機軟件界的廣泛重視，因為它代表了一種積極的方向——多種方法相互借鑒、相互融合、趨于一致、走向標準化。建模語言的標準化為軟件開發(fā)商及其用戶帶來了諸多便利。

UML1.x是為軟件行業(yè)制定的一種交互語言，用來給軟件的各個階段提供交流手段。UML2.x基于UML1.x的成功結(jié)果，嘗試對世間萬物進行建模，在解決了一些UML1.x問題的基礎(chǔ)上增加了許多圖例來支持更多行業(yè)的建模要求。

3、為何選擇UML語言作為需求的整理語言

UML語言是一種面向?qū)ο蟮慕ＵZ言，適合用來輔助了解復(fù)雜的系統(tǒng)和結(jié)構(gòu)，具有比較高的思維同質(zhì)性。我們可以想象一下，如果我們要為一盤圍棋進行建模，將所有的圍棋棋子都看成對象，這樣理解其行為容易還是從過程的角度來思考所有圍棋容易。從面相對象角度，我們只需要關(guān)心每個棋子每一瞬間的位置和行為即可。

UML語言適用于系統(tǒng)所有階段的建模，它提供了多種方式來體現(xiàn)信息內(nèi)容。這些表現(xiàn)非常容易被系統(tǒng)和軟件周期的各個階段的成員進行理解，方便了各個階段成員之間的交流。

UML語言提供了大量的表現(xiàn)方式，使用者可以從多種維度描述系統(tǒng)和架構(gòu)的相關(guān)信息。無論是系統(tǒng)、架構(gòu)、軟件、硬件、嵌入式、功能、非功能等都可以使用不同的UML語言圖例進行精確描述將實施過程碰到的信息和內(nèi)容進行沉淀。而且，汽車行業(yè)的業(yè)務(wù)行為復(fù)雜，需要一種能夠兼容各種要求的模式進行表現(xiàn)。

當(dāng)前汽車行業(yè)蓬勃發(fā)展，軟件定義汽車的概念越來越普及。固有的思路和傳統(tǒng)的方法已經(jīng)無法支持新概念的引入，同時也存在固有理念影響了新概念引入整車的情況（例如元宇宙、SOA服務(wù)驅(qū)動等），從正向角度思考汽車系統(tǒng)和汽車軟件的開發(fā)流程越來越得到重視。這也是汽車行業(yè)發(fā)展的未來方向。未來的汽車就是一個帶有四個輪子的手機。如何能夠?qū)⑺行滤枷搿⑿赂拍钜肫囆袠I(yè)，如何落地，都期待新的火花的出現(xiàn)。

需求分析和業(yè)務(wù)分析是一個過程，是一個整理思路的過程，使用工具是輔助我們梳理思路。是一個比較復(fù)雜的整理和匹配要求的方式，沉淀后得到一個統(tǒng)一的結(jié)果。使用 PREEvision 編寫的內(nèi)容可以理解為是一個結(jié)果，產(chǎn)生這個結(jié)果的過程需要更多的專業(yè)的好行業(yè)的知識的注入。

4、進行汽車行業(yè)的需求整理需要用到的一些圖例

用例圖

原則上來說，用例圖并不是一種面向?qū)ο蟮膱D形，UML引入用例圖的目的是為了能夠在UML進行面向?qū)ο蠼r，提供一個基礎(chǔ)和入口，以及劃定分析設(shè)計的邊界。

Use Case 用例圖主要包含Actor 和 use case兩樣?xùn)|西，use case 是一組連續(xù)行為的集合，例如“打開門”等。事件可大可小，原則上并沒有嚴格約束。Actor用來描述對該事件的驅(qū)動者或者該事件關(guān)聯(lián)的外部各方。我們也可以通過Region域的劃定來將用例放置于指定的限定的范圍內(nèi)。Actor和Use Case之間的連線代表交互關(guān)系。

活動圖

活動圖用來描述行為的過程，可以表示行為執(zhí)行的步驟和過程中的并發(fā)、條件、選擇、合并等行為的體現(xiàn)。

順序圖

順序圖用來描述強時間要求的順序行為。精確體現(xiàn)對象之間的驅(qū)動和執(zhí)行關(guān)系。UML2.0為了增強sequence順序圖的功能，加入了fragment的概念，讓順序圖可以表現(xiàn)一些可重用的順序塊和邏輯信息，例如條件分支等。

狀態(tài)機

State Machine 狀態(tài)機圖體現(xiàn)的是事物狀態(tài)以及狀態(tài)之間變化的關(guān)系，以及變化的驅(qū)動源等信息。狀態(tài)機能夠很好地體現(xiàn)事物的一些靜態(tài)特性。

類圖

在UML語言當(dāng)中，所有需要沉淀的內(nèi)容都需要通過類圖（或類相關(guān)圖）進行沉淀的。在需求整理過程中，并不一定要類圖參與，但是類圖的參與能夠更好地將需求內(nèi)容延續(xù)到后期的架構(gòu)和軟件過程當(dāng)中。

5、如何開啟汽車行業(yè)的需求分析過程

什么是需求

所謂需求，是指因為欲求引發(fā)的某種動機，這個動機就是需求。我們一般的理解是利益相關(guān)者stakeholder對系統(tǒng)的一種要求。需求有業(yè)務(wù)需求、用戶需求和功能需求等。

如何描述用戶的需求呢？對于軟件行業(yè)我們一般會從業(yè)務(wù)的角度去描述用戶的需求，更直觀地，我們會通過冰山模型來表現(xiàn)

用戶要實現(xiàn)的功能就是整座冰山，冰山浮出水面的部分就是用戶的需求，用戶需求就是冰山對于用戶的可見部分。所謂可見部分，包括視覺、聽覺、觸覺、味覺在內(nèi)的各種感知。例如主機廠要求的用戶需求，可以是中控屏的操作，可以是雷達的聲響，也可以是語音與SIRI 的對話過程。我們觸碰雨刮開關(guān)，導(dǎo)致雨刮擺動，這也是主機廠能夠感覺到的用戶需求。通過對冰山水面可見部分的分析和理解，搭建出整個能夠支持冰山的不可見部分的內(nèi)容。

汽車行業(yè)需求分析過程，可以區(qū)分為業(yè)務(wù)建模、系統(tǒng)建模以及軟件建模過程三個階段，

業(yè)務(wù)建模

業(yè)務(wù)建模是將業(yè)務(wù)相關(guān)過程進行完整梳理，將軟件功能和非軟件功能進行確認和分離，從而將需求工作的重點集中在需求的軟件部分。

例如我們在研究一個自動洗車過程，自動洗車應(yīng)該包含：

1.將車(自動)從停車場開到洗車房

2.點擊系統(tǒng)開啟自動洗車模式（自動洗車模式關(guān)閉窗戶、停止雨刮、關(guān)閉空調(diào)、鎖住后車門、關(guān)閉車身保護雷達等）

3.將汽車檔位掛在N空擋位置

4.洗車房機器開始洗車過程

5.洗完車關(guān)閉自動洗車模式（恢復(fù)天窗、雨刮等的狀態(tài)）

6.將車（自動）從洗車房開回停車場

業(yè)務(wù)建模及業(yè)務(wù)分析過程是必須有的，但是在整理整車業(yè)務(wù)需求時可以簡化相關(guān)過程。通過業(yè)務(wù)建模后，我們判斷1和6，汽車從停車場自動開到洗車房并回來的過程現(xiàn)在依然不成熟，所以無法支持，于是將這個過程分析為人為處理實現(xiàn)。對于4，無需人為干預(yù)。對于3，需要人為將物理檔位切換，當(dāng)前車身并不具備這個功能，但是我們可以編寫一個用戶指引guideline來引導(dǎo)用戶完成洗車過程。于是，對于2和5將被分析成系統(tǒng)需求，交由自動洗車功能模塊來完成。

系統(tǒng)建模

系統(tǒng)建模的目的是將車身功能進行分析和細化，依據(jù)用戶可感知的部分的信息，搭建起整個系統(tǒng)的架構(gòu)。就是參考冰山可見部分構(gòu)建出整個冰山的內(nèi)容。描述冰山可見部分可以理解為系統(tǒng)需求過程，構(gòu)造出支撐可見部分的整個冰山可以理解為系統(tǒng)架構(gòu)、系統(tǒng)設(shè)計的過程。系統(tǒng)建模過程也需要考慮非功能性需求，例如安全、性能、法律法規(guī)等非功能性需求也會影響系統(tǒng)整個建模過程。

軟件建模

系統(tǒng)建模過程結(jié)束后，將設(shè)計結(jié)果轉(zhuǎn)換成軟件架構(gòu)實現(xiàn)的接口要求，一般是子系統(tǒng)的接口需求或者SOA服務(wù)的服務(wù)接口需求。軟件接口需求會定義軟件接口的名稱、參數(shù)信息和參數(shù)值、返回信息和返回值。參數(shù)信息和參數(shù)值之間存在一定的依賴關(guān)系，這些依賴關(guān)系也需要也需要通過一定的方式描述其內(nèi)部功能實現(xiàn)的流程關(guān)系。這些接口的定義信息就是軟件子系統(tǒng)的需求。

同時，軟件建模過程也會從系統(tǒng)建模過程細化出來各種非功能性需求，這些非功能性需求也會影響軟件建模和實現(xiàn)過程。

6、整車業(yè)務(wù)需求分析過程

這里主要講解的是系統(tǒng)需求分析的全過程，業(yè)務(wù)場景分析雖然包含在內(nèi)，但是會一帶而過。軟件分析過程可以參考傳統(tǒng)的軟件分析過程實施完成。

具體分析過程可以參考以下流程（并不是完整流程，可以根據(jù)具體企業(yè)的要求和場景進行調(diào)整）?？傮w流程氛圍業(yè)務(wù)場景分析和梳理、系統(tǒng)需求分析和梳理、系統(tǒng)需求細化、系統(tǒng)需求評審的過程。

業(yè)務(wù)場景分析的目的如下：

1.梳理出可以通過軟件實現(xiàn)的系統(tǒng)功能；

2.將功能硬件理解成軟件包（所有硬件功能的實現(xiàn)都由軟件進行代理完成）；

3.將硬件部分都理解成non-human 的actor，包括聲音，雷達等等可感知部分

4.梳理出涉及的human的actor，例如駕駛員、乘客等。

系統(tǒng)需求分析的目的如下：

1.識別所有系統(tǒng)用例，系統(tǒng)用例為一系列時間相關(guān)的行為總和。并將系統(tǒng)用例通過簡單的名稱進行描述；

2.將系統(tǒng)用例與actor以及non-human的actor進行關(guān)聯(lián)，清晰體現(xiàn)出所有系統(tǒng)用例的邊界；

3.將non-functional的非功能性需求進行描述以及體現(xiàn)；

4.將UI相關(guān)（界面、語音、雷達等交互）與非UI行為進行分離，單獨描述；

5.將所有涉及或影響到這個業(yè)務(wù)場景的事件也作為系統(tǒng)用例進行表現(xiàn)。但是要注意其Actor的識別，例如司機踩油門導(dǎo)致車速加快會啟動車門安全鎖，那么啟動這個驅(qū)動者的Actor將是車身，而不是駕駛員；

系統(tǒng)需求細化的目的如下：

1.將UI相關(guān)的用例，借助活動圖描述出頁面流轉(zhuǎn)的關(guān)系，主要體現(xiàn)出頁面，以及頁面切換的邏輯依賴關(guān)系。非頁面行為可以弱化成單個活動行為；

2.將非UI的用例細化成以功能實現(xiàn)為主線的活動圖，UI相關(guān)部分需要體現(xiàn)成UI類型活動圖；

3.對于外部事件相關(guān)的活動也需要轉(zhuǎn)換成活動圖；

4.細化過程的語言描述不可以存在歧義，存在歧義的文字描述需要在術(shù)語定義當(dāng)中進行定義；

5.對于一些部件或狀態(tài)類型的信息可以通過狀態(tài)機進行體現(xiàn)；

6.對于一些時間強相關(guān)的事件可以通過序列圖進行體現(xiàn)；

7.對于需要有信息沉淀或術(shù)語定義類型的信息，可以通過類圖進行體現(xiàn)。例如恢復(fù) “原來狀態(tài)” 就代表需要存在一個需要沉淀下來的信息。

需求評審的目的如下：

1.評審是一個周期性的行為，可以理解成檢查，主要目的是進行各個階段的把關(guān)工作。

2.需求評審和總需求交付評審不是一個概念，總交付評審是一個蓋章過程，需求各個階段的評審是對階段工作的檢查。

3.評審?fù)ㄟ^提前的同行交流、跨部門交流、架構(gòu)師檢查等方式來發(fā)現(xiàn)需求階段存在的問題。

4.由于需求人員的背景和知識能力的差異，可以通過評審來減少錯誤，同時達到提高專業(yè)能力和實現(xiàn)共識的目的。

7、整車業(yè)務(wù)系統(tǒng)需求分析的一些要點

在需求分析的時候需要注意以下幾點：

1.非功能性需求需要依賴不同的要求進行描述和表示，可能是圖形也可能是文字表格，目的是能夠體現(xiàn)需求的特點和相關(guān)性。此次并不會對非功能性需求描述過多，更多的需求表述可以另設(shè)話題討論。

2.不管是需求分析，還是架構(gòu)設(shè)計，都是一個遞進的過程，圖形隨著分析的遞進，逐步細化和深入。當(dāng)前展示的內(nèi)容主要是展示分析結(jié)果，相關(guān)分析過程信息將會通過文字表示。

3.使用UML進行需求分析，目的都是為了能夠簡化和清晰需求描述，做到簡化和解耦的目的，部分難以表述的內(nèi)容會建議采用文字表述的方式進行表達。

4.圖形的多少并不是越多越好，判斷標準就是是否能夠清晰表達需求的信息。當(dāng)然，另外一個判斷標準就是：任何人拿著需求文檔都能夠通過UML和文字清晰了解需求內(nèi)容即可。所以并沒有嚴格的標準。

5.需求的編寫是以UML管理的目錄結(jié)構(gòu)為基礎(chǔ)，Word文檔和Excel的表述只是它的一種展示方式。

6.當(dāng)前需求的編寫是通過UML Designer軟件進行編寫，通過工具，能夠更好地管理和定位軟件模型，這個工具本身并不能完美支持UML2.x的所有內(nèi)容，為了避免切換工具的時候帶來的移植問題，編寫圖形時都使用標準的圖形即可。

8、整車業(yè)務(wù)系統(tǒng)需求分析實例

總述

該文檔的編寫是以一個《自動洗車功能》作為基礎(chǔ)，自動洗車功能概述如下：自動洗車功能是為了使用戶能夠快速自動洗車，在進入自動洗車機前，通過快捷按鍵一次性完成關(guān)窗、停止雨刮、關(guān)閉雷達、禁止開啟后車門等操作，并且在洗車完成后通過快捷按鍵恢復(fù)各個相關(guān)零部件洗車前狀態(tài)。自動洗車模式包括進入自動洗車模式、退出自動洗車模式、自動洗車模式保持期間對相關(guān)零部件的操作的三大部分。各個功能需求通過需求整理和車型對標獲得。

下圖是自動洗車模式層次架構(gòu)的樣貌。整個需求分析過程是一個遞進過程，分析過程會產(chǎn)生許多圖形和結(jié)構(gòu)以及關(guān)系，可以使用package包分類管理起來。

模型是UML定義的元對象，圖形 diagram是模型在不同側(cè)面的一個體現(xiàn)，根據(jù)需要將特定的UML模型進行展示和體現(xiàn)，根據(jù)需求在圖形上進行取舍。圖形展示并不會影響模型之間的關(guān)系，圖形可以看成只是一個輔助工具而已。

用例

首先第一步是進行用例的確定，確定的基本方向為：1.UI與非UI進行分離。2.將正常業(yè)務(wù)與異常業(yè)務(wù)場景進行分離。3.異常業(yè)務(wù)場景單獨體現(xiàn)。4.由于觸及的外部零部件都是可見部分，所以將外部零部件都作為單獨的non-human actor來體現(xiàn)。

下圖A中，UI進入自動洗車模式表示通過中控屏啟動功能的過程，虛擬按鍵點擊和語音交互都是一種UI的啟動方式而已。因為這里是UI用例，UI用例是借助UML來體現(xiàn)UI交互過程，它并不是一個真實的用例的概念，所以我們只需要關(guān)心驅(qū)動者是駕駛員即可，無需考慮零部件的相關(guān)行為。

下圖B中，對中控屏主動控制，發(fā)出信號的是駕駛員，每個用例我們可以理解成一塊軟件團完成的功能。窗戶雨刮等為non-human的actor，這些作為外部部件。未來經(jīng)過架構(gòu)階段的推導(dǎo)，外部部件都會很自然地變成一個一個的子系統(tǒng)或服務(wù)，但這是后話。這個階段，我們只需要將冰山上可見部分，就是用戶可感知部分，都作為外部的actor考慮即可。對于關(guān)閉自動洗車模式的行為，在用戶無意中改變了檔位以后，一樣會觸發(fā)關(guān)閉自動洗車模式的行為，所以我們將這個行為作為擴展考慮。其原因是我們幾乎不用增加任何的描述就可以體現(xiàn)更改檔位導(dǎo)致的變化，也可以理解為我們在進行用例細化的時候只需要細化其中一個用例即可。

下圖C中，表現(xiàn)的是自動洗車模式場景ongoing的狀態(tài)時，某些對空調(diào)、窗戶等硬件操作后會影響自動洗車模式的情況。簡單來說，就是洗車模式關(guān)閉的時候會將相關(guān)零部件恢復(fù)到進入洗車模式前的狀態(tài)，但是如果零部件被觸碰，例如天窗被調(diào)整以后，退出時將忽略天窗的恢復(fù)。由于該事件的完整行為過程為外部器件驅(qū)動并記錄外部事件的信息，因此用例定義簡單。

A.UI相關(guān)用例	B.功能用例	C.外部事件用例

用例活動

有的用例內(nèi)容可以通過其他用例的信息體現(xiàn)，所以無需進行用例活動描述，能夠體現(xiàn)用例信息的用例需要將用例實現(xiàn)過程，即所有涉及可見/可感知的行為，都通過活動圖體現(xiàn)出來。文字表達不能模糊，必須清晰體現(xiàn)具體行為，對于某些詞匯定義，可以在詞匯表進行解釋。

對于UI相關(guān)的用例，主要是體現(xiàn)UI交互/語音交互的交互過程，甚至包括硬件操作過程，弱化非UI部分的內(nèi)容。如果圖形不能表達清楚，可以通過文字進行補充。

描述UI活動過程中，需要把事件和行為進行分離。流程描述的是事件，例如按下按鈕是確認行為，而不是點擊按鈕或語音（小度，小度，我選一）確認?？梢酝ㄟ^文字描述體現(xiàn)這個按鈕確認行為，包含通過鼠標點擊和語音確認兩種方式。

對于UI的action采用自定義的方式表示，紅底表示UI相關(guān)，白底的活動為非UI/軟件行為層面的行為。

對于非UI的業(yè)務(wù)流程，必要的地方依然會描述出UI活動，更多的內(nèi)容需要分析軟件判斷邏輯，這些邏輯和行為基本是與actor相關(guān)的。非UI流程里，所有涉及到的外部Actor（human actor或non-human actor）交互的過程都應(yīng)該在活動圖里進行體現(xiàn)。有時候，UI活動的結(jié)束就是非UI的開始。

對于外界事件的影響，根據(jù)實際情況將用例的活動描述轉(zhuǎn)換成活動圖進行表現(xiàn)。

類圖

根據(jù)實際情況，將類圖進行抽取和表現(xiàn)。

類圖的來源包括：

1.術(shù)語定義

2.狀態(tài)機抽象

3.關(guān)鍵實體對象

4.存儲管理信息

5.模糊術(shù)語定義

在UML語言當(dāng)中，所有需要沉淀保存和管理的信息都是通過類來實現(xiàn)的，類圖可以體現(xiàn)出實體的信息。進行類圖抽象，可以輔助后續(xù)架構(gòu)設(shè)計進行類的抽取。因此，根據(jù)實際情況抽取類圖。

當(dāng)前類圖并沒有很好地體現(xiàn)實體的內(nèi)容，并不是一個合理的類圖信息的展示，但是卻能夠體現(xiàn)需求整理者對各種信息的理解?；谶@些信息，架構(gòu)設(shè)計人員可以根據(jù)類圖進行參考和對實體對象信息的收集。

狀態(tài)機圖

狀態(tài)機可以清晰體現(xiàn)出對象的狀態(tài)的類型、狀態(tài)之間切換的條件以及方向等信息。

下圖為后視鏡的狀態(tài)信息，包含折疊和展開。這個狀態(tài)機也體現(xiàn)了狀態(tài)之間進行切換的時候的行為以及轉(zhuǎn)換方向等信息。

下圖展示了一個二維的狀態(tài)變化管理，通過狀態(tài)機表現(xiàn)兩個狀態(tài)類型轉(zhuǎn)換之間的關(guān)系信息等。

其他模型

由于當(dāng)前進行需求分析的方式是采用工具UML，更多的是通過圖形方式展示結(jié)構(gòu)和關(guān)系類型。但是圖形不是萬能的，有時候一兩句話就能夠簡化和體現(xiàn)相關(guān)信息，所以文字描述也可以適當(dāng)使用。同時，任何的理解和共識信息都可以通過文字進行描述，方便相關(guān)人員的同步和理解。

基于UML模型的管理結(jié)構(gòu)，存在presentation角度的圖形管理展示，可以借助工具進行展示。雖然工件artifact和關(guān)系是UML語言的基礎(chǔ)，圖形只是不同角度、不同側(cè)面的展示方式而已，但是人們接受信息的方式是通過圖形去體現(xiàn)的，所以圖形展示是一個重要的管理環(huán)境。

通過表格針對需要展示某些信息的列表以及描述信息的內(nèi)容進行體現(xiàn)。

http://mp.weixin.qq.com/s?__biz=Mzg5NzUyMjU1OA==&mid=2247483825&idx=1&sn=3e426e6fd5ea9c24f6b1ee768d60d854&chksm=c071cfa0f70646b6b86410df46e45e3d5817307930ab7f81c898eae7556ea589011c84a1fc69#rd