一種基于原型驅(qū)動(dòng)的軟件需求迭代細(xì)化方法

嚴(yán)振亞

（天津開發(fā)區(qū)先特網(wǎng)絡(luò)系統(tǒng)有限公司 天津300192）

一種基于原型驅(qū)動(dòng)的軟件需求迭代細(xì)化方法

嚴(yán)振亞

（天津開發(fā)區(qū)先特網(wǎng)絡(luò)系統(tǒng)有限公司 天津300192）

本方法改進(jìn)以"原型法"為基礎(chǔ)，通過在軟件界面原型的基礎(chǔ)上增加了"成員屬性信息"、"成員約束信息"和"非功能需求信息"3項(xiàng)內(nèi)容，用來描述原型的靜態(tài)屬性特征，同時(shí)使用"業(yè)務(wù)流程圖"和"數(shù)據(jù)流圖"定義系統(tǒng)的動(dòng)態(tài)特征。通過這些附加的信息項(xiàng)配合軟件原型界面，形成完整的需求定義。本方法還融入了敏捷過程中的"迭代細(xì)化"思想，在需求獲取和分析過程中通過不斷的迭代過程，使需求分析結(jié)果逐漸趨向于的用戶要求，最終形成一套完整的用戶需求文檔。使用本方法生成的文檔中不僅包括了軟件原型界面，還涉及到對(duì)于后續(xù)設(shè)計(jì)和開發(fā)階段非常重要的成員約束、非功能需求、業(yè)務(wù)流程、數(shù)據(jù)處理過程等內(nèi)容。它能夠有效的對(duì)軟件設(shè)計(jì)和開發(fā)過程進(jìn)行定義和限制，避免出現(xiàn)在需求分析過程中信息缺失而導(dǎo)致的開發(fā)風(fēng)險(xiǎn)。

軟件工程；方法改進(jìn)；原型驅(qū)動(dòng)；需求分析

近年來隨著軟件工程理論的創(chuàng)新，軟件需求分析方法呈現(xiàn)出多樣化的發(fā)展趨勢(shì)，研究人員針對(duì)不同的用戶群體與應(yīng)用場(chǎng)景，提出了一系列的軟件需求獲取與分析技術(shù)。“原型法”做為眾多的需求分析方法之一，由于其具有簡(jiǎn)單、易用、快速、易于交流等優(yōu)點(diǎn)得到了廣泛的應(yīng)用[1]。

原型法通常又分為兩種不同的應(yīng)用形式，它們分別是“拋棄型原型”和“演化型原型”[2]。

拋棄型原型是指在經(jīng)過若干次原型調(diào)整，得到軟件的明確的需求，此時(shí)的原型界面已經(jīng)完成了它的使命，后期的設(shè)計(jì)與開發(fā)過程將不再使用這些原型[3]。拋棄型原型的目的僅僅為了取得用戶對(duì)系統(tǒng)的需求信息，后續(xù)可以使用面向過程或面向?qū)ο蟮姆绞綄?duì)這些需求做進(jìn)一步的細(xì)化分析。

演化型原型則與拋棄型原型相反，在獲取明確的用戶需求后，這些原型并不會(huì)拋之不用，而是在此基礎(chǔ)做進(jìn)一步的細(xì)化設(shè)計(jì)[4]。如：將這些原型設(shè)計(jì)圖做為用戶界面，并根據(jù)它設(shè)計(jì)出物理數(shù)據(jù)模型和程序的業(yè)務(wù)邏輯模塊，并交付開發(fā)團(tuán)隊(duì)編寫代碼，這些原型設(shè)計(jì)圖最終會(huì)逐步演化為用戶看到的軟件界面。

1 原型驅(qū)動(dòng)方法主要缺陷

“軟件界面原型”的信息承載量非常有限，它雖然可以直觀、清晰的反應(yīng)出軟件在實(shí)際操作時(shí)用戶可以看到的界面效果，但很多隱含式的需求卻沒有得到正確的體現(xiàn)。這些隱性需求對(duì)軟件開發(fā)過程非常重要，有時(shí)正是因?yàn)闆]有正確的捕獲到這些信息而導(dǎo)致軟件開發(fā)失敗。原型法主要缺陷表現(xiàn)在以下幾個(gè)方面。

1.1 沒有體現(xiàn)出信息的“約束”關(guān)系

軟件系統(tǒng)中對(duì)于數(shù)據(jù)通常會(huì)有一些規(guī)定和限制，如：“金額”只能輸入數(shù)值型數(shù)據(jù)，并最多允許2位小數(shù)；“年齡”不能為負(fù)數(shù)，且不能超過一定的范圍；“手機(jī)號(hào)碼”為11位長(zhǎng)度的字符串，且只能為0-9的數(shù)字等等。這些約束信息無法在界面中體現(xiàn)，通常也極容易被用戶和需求分析人員忽略。

1.2 缺少非功能需求的相關(guān)描述

非功能需求對(duì)于軟件至關(guān)重要，對(duì)于用戶而言非功能需要包括軟件的性能、安全性、易用性、美觀等方面；對(duì)于程序開發(fā)團(tuán)隊(duì)，非功能需求還包括代碼易理解性、可移植性、可擴(kuò)展性等技術(shù)方面的要素[5]。這些需求在“軟件原型”設(shè)計(jì)圖中根本無法體現(xiàn)，也是容易被忽略的一個(gè)方面。

1.3 缺少業(yè)務(wù)流程層面的信息

“界面原型”是以操作界面為基礎(chǔ)的若干設(shè)計(jì)圖組成的模型，它們雖然可以體現(xiàn)出用戶操作時(shí)計(jì)算機(jī)所能呈現(xiàn)的內(nèi)容，但依附這些界面的業(yè)務(wù)流卻沒有得到展現(xiàn)[6]。正是由于這些業(yè)務(wù)流程支撐起軟件的運(yùn)行環(huán)境，缺少這些流程作為“骨架”的軟件系統(tǒng)將很難完成系統(tǒng)預(yù)期的功能。

1.4 缺少數(shù)據(jù)流層面的信息

信息系統(tǒng)會(huì)與大量的數(shù)據(jù)交互，在運(yùn)行過程中會(huì)由用戶向系統(tǒng)輸入數(shù)據(jù)，同時(shí)也會(huì)由系統(tǒng)生成大量的處理結(jié)果數(shù)據(jù)。因此應(yīng)著重從數(shù)據(jù)流層面對(duì)這些數(shù)據(jù)進(jìn)行梳理和分析，分析結(jié)果會(huì)做為系統(tǒng)的數(shù)據(jù)視圖參與到整體的設(shè)計(jì)過程[7]。但“軟件原型”中卻無法包含這部分信息，所有的數(shù)據(jù)流都被掩蓋到系統(tǒng)界面的背后，這些風(fēng)險(xiǎn)逐漸積累最終帶入到軟件后續(xù)的設(shè)計(jì)與開發(fā)環(huán)節(jié)。

2 基于原型驅(qū)動(dòng)方法的改進(jìn)

本方法改進(jìn)是以原型法為基礎(chǔ)，在繪制原型界面時(shí)添加了成員屬性信息、成員約束信息和非功能需求信息等內(nèi)容，用來描述軟件原型界面的靜態(tài)屬性。同時(shí)針對(duì)每個(gè)原型界面配合業(yè)務(wù)流程圖和數(shù)據(jù)流圖，從動(dòng)態(tài)層面表述系統(tǒng)特征，還配合使用“界面功能描述”從系統(tǒng)功能視角對(duì)原型界面進(jìn)行定義。在完成以上原型功能定義后，會(huì)通過需求定義、內(nèi)部評(píng)審、用戶確認(rèn)、需求調(diào)整細(xì)化等步驟對(duì)原型設(shè)計(jì)進(jìn)行迭代細(xì)化，經(jīng)過若干次迭代后最終會(huì)得到用戶實(shí)際需求的設(shè)計(jì)文檔。原型驅(qū)動(dòng)方法流程如圖1所示。

圖1 原型驅(qū)動(dòng)方法流程

2.1 繪制軟件界面原型

在與用戶充份溝通后，首先需要繪制軟件的界面原型圖。可以采用設(shè)計(jì)工具，如Visio、Axure等，也可以使用紙筆的方式進(jìn)行手工繪制。原型界面中要以功能為中心，清晰直觀的體現(xiàn)出與用戶交互的所有元素，建議使用通用控件展示交互界面[8]。在必要時(shí)原型界面中還要體現(xiàn)出軟件與用戶交互后返回的結(jié)果，如系統(tǒng)提示、查詢結(jié)果與列表等。軟件界面原型不僅要涉及到正確的事件流，也要繪制異常事件流時(shí)的界面，類似于系統(tǒng)報(bào)錯(cuò)、流程中斷、程序異常時(shí)涉及到的系統(tǒng)頁(yè)面都應(yīng)包含在原型設(shè)計(jì)中。

原型設(shè)計(jì)圖要貫穿系統(tǒng)的主要業(yè)務(wù)流程，不能出現(xiàn)跳躍或缺失的現(xiàn)象。對(duì)于非主干流程的分支，可以不必設(shè)計(jì)軟件界面原型圖，此時(shí)只在相應(yīng)位置使用文字說明即可。常見的場(chǎng)景包括編輯信息時(shí)的彈出窗口、系統(tǒng)二次確認(rèn)提示框等。

2.2 描述系統(tǒng)靜態(tài)屬性

通過軟件界面原型僅能體現(xiàn)很少一部分需求信息，在本改進(jìn)方法中需要配合“成員屬性信息”、“成員約束信息”和“非功能需求信息”對(duì)軟件原型做進(jìn)一步的限定和說明。

2.2.1 成員屬性信息

在軟件原型中包含很多成員（控件），僅通過界面只能確定成員的類型和位置，而與成員相關(guān)的其它信息則很難在原型中體現(xiàn)出來。如成員ID、是否可見、是否可用、跳轉(zhuǎn)編號(hào)、詳細(xì)描述等，此時(shí)需要配合使用“成員屬性信息表”對(duì)這部分隱含信息進(jìn)行描述。

在成員屬性信息表中，每一行代表頁(yè)面上的一個(gè)成員信息，它由“成員ID”唯一標(biāo)識(shí)。在命名時(shí)建議采用“小駝峰式命名法”，第一個(gè)單詞是成員的類型縮寫，后接成員名稱，如frmMain則表示是一個(gè)窗體類型的控件，btnSave則表示是一個(gè)保存按鈕。

“可見性”表示在程序運(yùn)行過程中成員是否可以顯示給用戶，某些成員可能確實(shí)要存在于系統(tǒng)中，但由于業(yè)務(wù)要求用戶不可見，此時(shí)應(yīng)使用“可見性”對(duì)這些成員進(jìn)行標(biāo)識(shí)[9]。

“可用性”則是指用戶是否可以實(shí)行某些操作，此時(shí)應(yīng)使用“可用性”屬性對(duì)其標(biāo)識(shí)[10]。

成員屬性信息表中的“跳轉(zhuǎn)編號(hào)”表示用戶在按TAB鍵時(shí)，界面焦點(diǎn)在不同成員間的跳轉(zhuǎn)順序。這個(gè)特性在軟件使用過程中非常重要，可以很大程度上提高用戶的工作效率，因此也需要在系統(tǒng)靜態(tài)屬性中體現(xiàn)出來。成員屬性信息表如表1所示。

表1 成員屬性信息表

2.2.2 成員約束信息

在很多軟件系統(tǒng)中，對(duì)用戶從界面中輸入的內(nèi)容會(huì)有一定的限制[11]。如身份證號(hào)只能由15或18位數(shù)字組成，且僅在18位身份證號(hào)時(shí)，末位才允許出現(xiàn)字母“X”，金額只能為數(shù)值類型，且最多允許2位小數(shù)等。諸如上述約束信息在軟件原型界面中通常無法表示，從而導(dǎo)致在進(jìn)行需求獲取過程中丟失了這部分內(nèi)容，此時(shí)需要配合使用“成員約束信息表”對(duì)這部分隱含信息進(jìn)行描述。

在“成員約束信息表”中可以根據(jù)軟件系統(tǒng)的實(shí)際需求定義需要對(duì)數(shù)據(jù)項(xiàng)進(jìn)行限定的內(nèi)容，一般情況下可以包括“成員 ID”、“接收類型”、“數(shù)值長(zhǎng)度”、“小數(shù)位數(shù)”、“接收范圍”和“其它”等信息項(xiàng)。成員約束信息表如表2所示。

表2 成員約束信息表

“成員ID”用來指定一個(gè)唯一的成員，它與“成員屬性信息表”中的ID值對(duì)應(yīng)。“接收類型”表示此成員如果可以接收用戶的輸入信息，則必須輸入何種類型的數(shù)值，如可以接收“任意字符”或只能接收“數(shù)字”等。“長(zhǎng)度”用來限制用戶輸入信息時(shí)的最大字符數(shù)量，超過這個(gè)限制的則不能被系統(tǒng)接收。如果輸入的是數(shù)值類型的數(shù)據(jù)，還需要使用“小數(shù)”對(duì)其進(jìn)一步限制，限定輸入數(shù)字所包含的小數(shù)長(zhǎng)度。“范圍”條件用來約束數(shù)值必須在某一個(gè)區(qū)間內(nèi)。“其它”起到備注作用，可以用來說明附加信息。

通過使用“成員約束信息表”對(duì)軟件原型進(jìn)行限制性說明，可以從系統(tǒng)接收內(nèi)容的角度對(duì)系統(tǒng)進(jìn)行限定。

2.2.3 非功能需求信息

軟件系統(tǒng)的需求通常由2部分組成，分別為功能需求和非功能需求[12]。功能需求指執(zhí)行用戶業(yè)務(wù)邏輯時(shí)需要軟件完成的具體功能，非功能需求是指與功能無關(guān)但卻是系統(tǒng)必不可少的組成部分，一般包括安全性、準(zhǔn)確性、成熟性、容錯(cuò)性、易理解性、易學(xué)習(xí)性等軟件的征性。在繪制軟件原型界面時(shí)，應(yīng)配合使用“非功能需求列表”對(duì)這些隱含特性進(jìn)行表述。非功能需求信息表如表3所示。

表3 非功能需求信息表

可以根據(jù)軟件系統(tǒng)的實(shí)際情況，在表格中列出系統(tǒng)需要實(shí)現(xiàn)的非功能需求，并對(duì)這些需求進(jìn)行分類標(biāo)注，方便后期進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)使用。“詳情”列中需要描述要實(shí)現(xiàn)的非功能要求，應(yīng)以可量化標(biāo)準(zhǔn)對(duì)這些需求進(jìn)行表述，如“數(shù)據(jù)檢索必須在1.5秒內(nèi)完成”等，避免使用模棱兩可的表達(dá)方式。

2.3 描述系統(tǒng)動(dòng)態(tài)屬性

軟件原型界面中除了要表述與成員、非功能需求等有關(guān)的靜態(tài)特征外，還會(huì)涉及到系統(tǒng)的業(yè)務(wù)邏輯功能[13]。這些信息也是需求調(diào)研中的重要部分，應(yīng)與系統(tǒng)原型界面配合加以說明。

2.3.1 業(yè)務(wù)流程圖

軟件系統(tǒng)中包含了大量的流程信息，這些流程貫穿起來實(shí)現(xiàn)完整的業(yè)務(wù)功能，針對(duì)每個(gè)界面原型也會(huì)包含相應(yīng)業(yè)務(wù)流程[14]。此時(shí)可以針對(duì)原型設(shè)計(jì)出與其相關(guān)的流程圖，以描述相關(guān)的工作流信息。業(yè)務(wù)流程圖如圖2所示。

圖2 業(yè)務(wù)流程圖

針對(duì)于每個(gè)原型界面的流程圖，都要以“前置條件”做為流程的始點(diǎn)，并以“后置條件”做為流程的終點(diǎn)，圖中僅表述當(dāng)前頁(yè)面涉及的流程即可。“前置條件”是指流程啟動(dòng)時(shí)應(yīng)具備的初始條件，如果缺少這些條件則流程無法啟動(dòng)。“后置條件”是指流程執(zhí)行完成后所處的系統(tǒng)狀態(tài)。如：“檢索數(shù)據(jù)”功能的前置條件是用戶已經(jīng)成功登錄系統(tǒng)并正常打開“查詢商品”窗體，而后置條件則為將查詢結(jié)果返回給用戶或顯示查詢時(shí)的錯(cuò)誤信息。業(yè)務(wù)流程前置/后置條件如表4所示。

表4 業(yè)務(wù)流程前置/后置條件

2.3.2 數(shù)據(jù)流圖

軟件原型界面中如果涉及到數(shù)據(jù)流程，則需要使用“數(shù)據(jù)流圖”對(duì)單個(gè)原型界面進(jìn)行表述。數(shù)據(jù)流圖是從數(shù)據(jù)流動(dòng)和處理的視角對(duì)軟件進(jìn)行觀測(cè)，它通常包括數(shù)據(jù)流、數(shù)據(jù)源或宿、數(shù)據(jù)處理、數(shù)據(jù)存儲(chǔ)等幾個(gè)主要組成元素[15]。數(shù)據(jù)流圖如圖3所示。

圖3 數(shù)據(jù)流圖

在數(shù)據(jù)流圖中只需要表述出本界面中涉及到的數(shù)據(jù)和處理即可，而與本原型無關(guān)的數(shù)據(jù)流則可以忽略。在數(shù)據(jù)流圖中還應(yīng)使用文字標(biāo)示出圖中所包含的元素類型及相對(duì)應(yīng)的名稱，如本例中包括源點(diǎn)/終點(diǎn)、外部實(shí)體和加工3種類型的元素，它們的名稱分別為用戶、商品目錄和檢索商品。數(shù)據(jù)流圖元素表如表5所示。

表5 數(shù)據(jù)流圖元素表

2.4 需求確認(rèn)及細(xì)化

完成上述的建模工作后，每個(gè)軟件原型所包含的內(nèi)容可以基本覆蓋系統(tǒng)的靜態(tài)屬性和動(dòng)態(tài)特征。接下來就需要將以上不同視角的軟件特性進(jìn)行歸納和整合，從頁(yè)面功能層面對(duì)系統(tǒng)原型進(jìn)行概括，形成“界面功能描述”文檔，將多個(gè)界面描述文檔逐級(jí)整合，完成整個(gè)系統(tǒng)的需求定義[16]。

接下來需要對(duì)完整的需求進(jìn)行內(nèi)部評(píng)審，主要從文檔邏輯、文檔規(guī)范、語(yǔ)法語(yǔ)義、和結(jié)果優(yōu)化4個(gè)方面評(píng)審需求文檔。“文檔邏輯”主要側(cè)重于評(píng)審對(duì)業(yè)務(wù)理解的正確性、一致性，是否存在與業(yè)務(wù)沖突，各頁(yè)面之間的關(guān)聯(lián)及接口是否有矛盾等。“語(yǔ)法和語(yǔ)義”則側(cè)重于需求定義中使用的自然語(yǔ)言是否符合常用的語(yǔ)法習(xí)慣，對(duì)于包含在文檔中的圖形是否符合建模語(yǔ)法的規(guī)定等。最后還要從整體上評(píng)審需求是否還有可改進(jìn)和優(yōu)化的空間，比如可在某些方面降低成本、提高軟件運(yùn)行效率、減少風(fēng)險(xiǎn)等。

內(nèi)部評(píng)審結(jié)束后即可將軟件需求原型交由用戶進(jìn)行確認(rèn)，用戶可能會(huì)根據(jù)實(shí)際情況對(duì)現(xiàn)有的需求進(jìn)行調(diào)整和細(xì)化，并將調(diào)整后的意見返回到需求調(diào)研部門，此時(shí)需要根據(jù)用戶本次的建議對(duì)軟件界面原型進(jìn)行適應(yīng)的調(diào)整，從而形成一次迭代細(xì)化的過程。系統(tǒng)原型界面經(jīng)過多次迭代后，會(huì)逐漸趨向于用戶的真實(shí)需求，最終由用戶確認(rèn)不需要進(jìn)一步迭代細(xì)化后，即完成需求收集和分析過程，接下來可以進(jìn)入到軟件設(shè)計(jì)階段。

3 結(jié) 論

在眾多的軟件需求收集和分析方法中，“原型法”是較為常用的一種方法，由于它具備了簡(jiǎn)單、方便、直觀、易于交流等優(yōu)點(diǎn)，因此可以在需求分析過程中節(jié)省大量的時(shí)間和成本。但由于原型本身的局限性，它無法體現(xiàn)出系統(tǒng)中涉及到的眾多靜態(tài)特性和動(dòng)態(tài)特性，使用這種方法也會(huì)給項(xiàng)目帶來一定的風(fēng)險(xiǎn)。

本過程改進(jìn)方法以“原型法”為基礎(chǔ)，添加了成員屬性信息、成員約束信息和非功能需求信息等附加說明，用來描述系統(tǒng)的靜態(tài)特性，同時(shí)還使用業(yè)務(wù)流程圖和數(shù)據(jù)流圖描述系統(tǒng)的動(dòng)態(tài)特性。它豐富了原型法的信息承載量，為后續(xù)的軟件設(shè)計(jì)和開發(fā)階段提供了更為詳細(xì)的參考數(shù)據(jù)。本過程還參考了敏捷開發(fā)中的“迭代”思想，通過多次迭代過程逐漸使系統(tǒng)需求趨向于用戶的真實(shí)需求，最終確定需求范圍和系統(tǒng)特征。

[1]董文彬.淺論軟件需求分析[J].科技視界，2012（26）:236-237.

[2]李超，謝坤武.軟件需求分析方法研究進(jìn)展[J].湖北民族學(xué)院學(xué)報(bào)：自然科學(xué)版，2013（2）:204-211.

[3]張帆，楊悅，周備戰(zhàn).敏捷需求分析方法在航天測(cè)控軟件中的應(yīng)用[J].飛行器測(cè)控學(xué)報(bào)，2013（5）:419-424.

[4]嚴(yán)亞瓊.基于敏捷建模方法的軟件需求分析研究及應(yīng)用[D].南昌：南昌大學(xué)，2014.

[5]賈超.軟件項(xiàng)目需求開發(fā)與管理過程方法研究[J].天津科技，2015（12）:49-51.

[6]張璇，李彤，王旭，等.可信軟件非功能需求形式化表示與可滿足分析[J].軟件學(xué)報(bào)，2015（10）:2545-2566.

[7]李雪源.淺論軟件需求分析[J].信息與電腦：理論版，2012（2）:43，45.

[8]符丁.一種從組織業(yè)務(wù)數(shù)據(jù)中獲取軟件需求的方法[J].現(xiàn)代計(jì)算機(jī)：專業(yè)版，2012（16）:29-32，40.

[9]郭輝，董瑞志.一種基于角色和協(xié)作的軟件需求獲取方法[J].常熟理工學(xué)院學(xué)報(bào)，2012（4）:115-119.

[10]鄧世垠.基于XML的快速原型方法[J].電腦知識(shí)與技術(shù)，2012（31）:7475-7477，7480.

[11]楊毅,楊杰.一種提高軟件需求分析質(zhì)量的方法[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2014（5）:16-20.

[12]張麗蕓，蒲戈光，王政，等.一種面向控制軟件需求分析的方法[J].計(jì)算機(jī)應(yīng)用研究，2013（2）:465-468，475.

[13]趙承乾.軟件需求分析方法創(chuàng)新分析[J].計(jì)算機(jī)光盤軟件與應(yīng)用，2013（3）:61，63.

[14]辜嘉惠.用例中活動(dòng)流程的一種描述方法[D].長(zhǎng)春：吉林大學(xué)，2012.

[15]王敏.銀行軟件開發(fā)項(xiàng)目需求管理研究[D].北京：中國(guó)科學(xué)院大學(xué)，2015.

[16]田良，楊溢.關(guān)于提高軟件需求分析質(zhì)量的幾點(diǎn)思考[J].電子技術(shù)與軟件工程，2015（5）:72.

An iterative refinement method of software requirement based on prototype driven

YAN Zhen-ya
（ESINT System Co.，Ltd.，Tianjin 300192，China）

The method is improved to"prototype"as the foundation，through the software interface prototype based on"increased the member attribute information"，"members of the constraint information"and"non function requirement information"three items，used to describe a prototype static attributes.At the same time，"the business flow chart"and"data flow diagram"to define the system's dynamic characteristics.Through these additional information items with the software prototype interface,the formation of a complete definition of requirements.The method is also integrated into the agile process"iterative refinement"thought and in the requirements elicitation and analysis process through the iterative process,make the demand analysis results tend to the requirements of users,and ultimately the formation of a complete set of user requirements document.Generated using the method of document includes not only the software prototype interface,also involves for subsequent design and development stage is very important members of the constraints,non functional requirements,business process,data processing of content.It can define and limit the process of software design and development,and avoid the risk of the development of the information loss in the process of requirement analysis.

software engineering； method improvement； prototype driven； requirement analysis

TP311.5

A

1674－6236（2017）16-0046-05

2016-08-19稿件編號(hào)：201608142

嚴(yán)振亞（1982—），男，天津人，碩士，副高級(jí)工程師。研究方向：軟件工程過程和系統(tǒng)架構(gòu)設(shè)計(jì)。