一種基于角色和協(xié)作的軟件需求獲取方法

郭輝，董瑞志

（常熟理工學(xué)院計(jì)算機(jī)科學(xué)與工程學(xué)院，江蘇常熟 215500）

一種基于角色和協(xié)作的軟件需求獲取方法

郭輝，董瑞志

（常熟理工學(xué)院計(jì)算機(jī)科學(xué)與工程學(xué)院，江蘇常熟 215500）

精確地獲取客戶的需求是一個(gè)必需的任務(wù).本文提出了在網(wǎng)絡(luò)協(xié)作平臺(tái)上的一個(gè)協(xié)作方法和過(guò)程.該方法有許多角色，每種角色在網(wǎng)絡(luò)環(huán)境下同時(shí)執(zhí)行一些需求編寫、復(fù)查、評(píng)論等任務(wù).不同的角色負(fù)責(zé)不同的任務(wù).基于協(xié)作方式，提出了一些角色關(guān)系.為了達(dá)到協(xié)作工作的目的，平臺(tái)提供了幾種協(xié)作服務(wù)，以滿足一個(gè)軟件系統(tǒng)的開(kāi)發(fā)需求.所有的用戶通過(guò)不同的協(xié)作模式完成他們的工作.所有的涉眾完成各自的需求編寫后，一個(gè)綜合的軟件需求文檔就會(huì)產(chǎn)生.

軟件工程；需求工程；面向?qū)ο螅唤巧粎f(xié)作

自軟件工程出現(xiàn)后，在軟件開(kāi)發(fā)中引入了軟件生命周期的概念.軟件需求階段在軟件開(kāi)發(fā)中起重要作用.在軟件需求分析階段確定的系統(tǒng)邏輯模型是以后設(shè)計(jì)和實(shí)現(xiàn)目標(biāo)系統(tǒng)的基礎(chǔ).軟件系統(tǒng)的成功極大地依賴軟件需求分析的質(zhì)量[1].軟件開(kāi)發(fā)失敗多數(shù)在于需求的模糊性，軟件需求的不充分性發(fā)現(xiàn)越晚，軟件開(kāi)發(fā)面臨風(fēng)險(xiǎn)越大.

進(jìn)入90年代后，需求工程成為軟件工程領(lǐng)域的研究重點(diǎn)之一.需求工程涉及到需求獲取、需求分析與協(xié)商、系統(tǒng)建模、需求規(guī)約、需求驗(yàn)證、以及需求管理[2].一個(gè)稱作KAOS的方法提出用于開(kāi)發(fā)需求工程，通過(guò)目標(biāo)提煉和目標(biāo)操作開(kāi)發(fā)軟件需求[3-5].Bolchini等通過(guò)面向目標(biāo)的分析導(dǎo)出Web應(yīng)用需求[6-7].Yu提出了I*framework作為面向Agent需求工程方法[8].軟件需求有兩類，一類是功能需求，另一類是非功能需求[9].多數(shù)研究集中在功能需求上.然而，一些研究者選擇忽略非功能需求，因?yàn)樗容^難.ChungMylopoulos提出用NFR framework去處理非功能需求[10-11].在NFR framework中，把軟件目標(biāo)分解成更詳細(xì)的軟件需求.目標(biāo)精化的結(jié)果用SIGs（softgoal interdependency graphs）圖來(lái)表示.最近，面向?qū)ο蟮能浖_(kāi)發(fā)越來(lái)越流行.RUP方法被證明是一個(gè)成功的軟件方法[12].現(xiàn)代大多數(shù)軟件開(kāi)發(fā)方法是使用UML[13].為了深入理解需求，I.Jacobson提出用了用例驅(qū)動(dòng)的方法進(jìn)行需求分析[14].

鑒于軟件需求的變化，涉眾和系統(tǒng)開(kāi)發(fā)人員的有效交流是非常重要的.但在這個(gè)問(wèn)題上卻研究不多.本文提出了一個(gè)多角色協(xié)作方法和平臺(tái).主要目標(biāo)是加強(qiáng)參與軟件項(xiàng)目的人員間的交流.包括不同的涉眾、分析員、經(jīng)理等等.通過(guò)加強(qiáng)交流，分析員更深刻地理解客戶的需求.另外，客戶借助分析員的幫助，表達(dá)更合適的需求.由于項(xiàng)目涉及到的人員分布在不同的地方，基于網(wǎng)絡(luò)環(huán)境是必需的.通過(guò)使用網(wǎng)絡(luò)平臺(tái)，人員可以在任何時(shí)候任何地點(diǎn)完成他們自己的工作.因此可以提高效率，節(jié)約時(shí)間.

本文定義了幾種角色和角色之間的關(guān)系.通過(guò)定義角色之間的關(guān)系，可以設(shè)計(jì)出協(xié)作機(jī)制，這種機(jī)制使得人們?cè)趨f(xié)作平臺(tái)上更容易滿足他們的工作.導(dǎo)出了幾種有用的協(xié)作模式，實(shí)際上，多數(shù)在協(xié)作平臺(tái)上的協(xié)作工作和任務(wù)遵照導(dǎo)出的協(xié)作模式，所有的涉眾完成了他們的需求編寫后，綜合的軟件需求文檔就會(huì)生成.

1 角色和角色關(guān)系

軟件系統(tǒng)開(kāi)發(fā)是一個(gè)需要協(xié)作的工作，特別是軟件需求開(kāi)發(fā)階段.在軟件需求開(kāi)發(fā)中涉及到一些人.因此，需定義幾種角色和角色關(guān)系.

1.1 角色

在多角色協(xié)作平臺(tái)上把角色分成三類，一類是客戶端，一類是系統(tǒng)開(kāi)發(fā)端，一類是中間協(xié)調(diào)者.多角色協(xié)作平臺(tái)中，共定義7種角色，客戶端有客戶秘書(shū)、涉眾、客戶經(jīng)理，系統(tǒng)開(kāi)發(fā)端有開(kāi)發(fā)秘書(shū)、分析員、開(kāi)發(fā)經(jīng)理，還有協(xié)調(diào)者.不同的角色有不同的特征和任務(wù).

協(xié)調(diào)者：負(fù)責(zé)建立順暢的通信途徑.

客戶秘書(shū)：與開(kāi)發(fā)秘書(shū)洽談決定誰(shuí)參加軟件需求的開(kāi)發(fā).

涉眾：使用系統(tǒng)的主要用戶，使用開(kāi)發(fā)平臺(tái)，不同的涉眾寫出各自的需求，其他涉眾做出評(píng)論，涉眾可根據(jù)評(píng)論修改他們的需求.

客戶經(jīng)理：與開(kāi)發(fā)經(jīng)理和涉眾交流，另外，客戶經(jīng)理負(fù)責(zé)管理監(jiān)督來(lái)自所有涉眾的需求.

開(kāi)發(fā)秘書(shū)：與客戶秘書(shū)洽談決定參加軟件需求開(kāi)發(fā)的人員.

系統(tǒng)分析員：負(fù)責(zé)系統(tǒng)分析，另外也通過(guò)協(xié)作機(jī)制幫助涉眾編寫他們的需求.

開(kāi)發(fā)經(jīng)理：與系統(tǒng)分析員和客戶經(jīng)理洽談，另外，開(kāi)發(fā)經(jīng)理負(fù)責(zé)協(xié)作軟件需求的產(chǎn)生.

1.2 角色關(guān)系

1.2.1 （客戶經(jīng)理/客戶秘書(shū)/涉眾/開(kāi)發(fā)秘書(shū)/開(kāi)發(fā)經(jīng)理/分析員）——協(xié)調(diào)者

這種關(guān)系涉及到所有角色，協(xié)調(diào)者在其它角色之間建立良好的溝通方式.

1.2.2 秘書(shū)-秘書(shū)洽談角色關(guān)系

一般地，可以把協(xié)作軟件開(kāi)發(fā)過(guò)程分為五個(gè)主要階段：建立順暢的通信途徑、角色分配、涉眾編寫、分析評(píng)論、協(xié)作軟件需求產(chǎn)生.在角色分配階段，至少有一個(gè)客戶秘書(shū)和開(kāi)發(fā)秘書(shū)一起討論洽談，決定不同的關(guān)系和分配不同人員執(zhí)行合適的角色.

1.2.3 涉眾-分析員協(xié)作角色關(guān)系

不同的涉眾使用協(xié)作平臺(tái)在分析員的幫助下書(shū)寫他們的需求，涉眾書(shū)寫各自的需求后，分析員可以通過(guò)對(duì)不完整的需求作出評(píng)論以幫助他們完成完整的需求.然后，涉眾可以按照分析員的評(píng)論修改或改進(jìn)他們的需求.可表示為：涉眾----------分析員.

1.2.4 （客戶經(jīng)理/涉眾）—開(kāi)發(fā)經(jīng)理角色關(guān)系

這個(gè)角色關(guān)系可表示為：涉眾-------------客戶經(jīng)理----------開(kāi)發(fā)經(jīng)理.

由三種角色構(gòu)成.主要的交流是客戶經(jīng)理和開(kāi)發(fā)經(jīng)理之間，另外，開(kāi)發(fā)經(jīng)理、客戶經(jīng)理也可與涉眾交流，這時(shí)，客戶經(jīng)理可被看作是涉眾和開(kāi)發(fā)經(jīng)理間的橋梁.

1.2.5 客戶經(jīng)理—（開(kāi)發(fā)經(jīng)理/分析員）角色關(guān)系

這種角色關(guān)系表示為：客戶經(jīng)理----------開(kāi)發(fā)經(jīng)理--------分析員.與（客戶經(jīng)理/涉眾）——開(kāi)發(fā)經(jīng)理角色關(guān)系相似，主要的區(qū)別在于開(kāi)發(fā)經(jīng)理是分析員和客戶經(jīng)理之間的橋梁.

1.2.6 （客戶經(jīng)理／涉眾）－（開(kāi)發(fā)經(jīng)理／分析員）的角色關(guān)系

這個(gè)角色關(guān)系為：涉眾----------客戶經(jīng)理----------開(kāi)發(fā)經(jīng)理---------分析員.

涉及到四種角色.這種關(guān)系主要集中在客戶經(jīng)理和開(kāi)發(fā)經(jīng)理之間，另外，客戶經(jīng)理也需要涉眾的支持和幫助.相似地，分析員可以幫助開(kāi)發(fā)經(jīng)理使得交流更加有效.

1.2.7 客戶經(jīng)理－開(kāi)發(fā)經(jīng)理角色關(guān)系

這種關(guān)系為：客戶經(jīng)理----------開(kāi)發(fā)經(jīng)理.

不同的涉眾分別完成各自的需求后，協(xié)作的軟件需求就會(huì)產(chǎn)生.然后，執(zhí)行協(xié)作軟件需求的驗(yàn)證.客戶經(jīng)理和開(kāi)發(fā)經(jīng)理共同完成驗(yàn)證.

2 協(xié)作機(jī)制

協(xié)作平臺(tái)為軟件需求開(kāi)發(fā)提供了一些協(xié)作服務(wù)，提供的協(xié)作服務(wù)形成了一些共同的協(xié)作模式，這些協(xié)作模式是協(xié)作平臺(tái)的基礎(chǔ)，用戶之間交互遵循協(xié)作平臺(tái)上的協(xié)作模式，這些協(xié)作模式支持主要的協(xié)作機(jī)制.

2.1 協(xié)作服務(wù)

本文提出在協(xié)作平臺(tái)上支持協(xié)作軟件需求開(kāi)發(fā)的四種協(xié)作服務(wù).協(xié)作編寫服務(wù)：提供用戶編寫、查看、評(píng)論需求.

支持工作服務(wù)：為用戶完成他們的工作提供一些支持.

綜合的規(guī)格說(shuō)明產(chǎn)生服務(wù)：編寫完需求后，這種服務(wù)提供產(chǎn)生軟件需求規(guī)格說(shuō)明的機(jī)制.

協(xié)作驗(yàn)證服務(wù)：提供需求驗(yàn)證的方法和環(huán)境.客戶經(jīng)理和開(kāi)發(fā)經(jīng)理互動(dòng)協(xié)作驗(yàn)證需求規(guī)格說(shuō)明.

2.2 協(xié)作模式

考慮到軟件需求的發(fā)展，需要提高軟件項(xiàng)目人員之間的交流，因此特別強(qiáng)調(diào)在基于網(wǎng)絡(luò)環(huán)境下的人員間的合作.下面介紹在協(xié)作平臺(tái)上的幾種普遍協(xié)作模式.

2.2.1 單一對(duì)等協(xié)作

一個(gè)人與另一個(gè)人交互，涉及到的角色有涉眾、分析員、客戶經(jīng)理、開(kāi)發(fā)經(jīng)理，如圖1（a）所示，這種模式的特征是交互僅發(fā)生在兩個(gè)人之間.單一對(duì)等協(xié)作是最基本的協(xié)作模式，作為一個(gè)基本的交互模式可以獨(dú)立工作.另外，這種模式可以混合其他模式以形成另外一種協(xié)作模式，這個(gè)協(xié)作模式包含兩種角色這種協(xié)作模式下有幾種類型的角色組合：涉眾與涉眾，涉眾與分析員，客戶經(jīng)理與開(kāi)發(fā)經(jīng)理，開(kāi)發(fā)經(jīng)理與分析員.

2.2.2 多對(duì)協(xié)作

同一種類的角色間交互涉及到的角色有涉眾，如圖1（b）所示，這種協(xié)作模式的特征是所有人都是同一角色.實(shí)際上，這種協(xié)作模式主要涉及到涉眾，涉眾編寫他們的需求，其他涉眾可以審查這些需求.

2.2.3 單一中心協(xié)作

有一個(gè)經(jīng)理作為管理員，經(jīng)理起到橋的作用.涉及到的角色有涉眾、客戶經(jīng)理、分析員、開(kāi)發(fā)經(jīng)理.如圖1（c）所示.這種模式的特征是有個(gè)人作為管理員.按照經(jīng)理的角色有兩種協(xié)作模式，客戶經(jīng)理起到管理員的作用，其他角色是涉眾，開(kāi)發(fā)經(jīng)理起到管理員的角色，其他角色是分析員.

2.2.4 多中心協(xié)作

在這種模式中，協(xié)作圖中包含兩類經(jīng)理.涉及到的角色有涉眾、客戶經(jīng)理、分析員、開(kāi)發(fā)經(jīng)理，如圖1（d）所示.這種模式的特征是這種模式發(fā)生在后期.這種模式集中在客戶經(jīng)理與開(kāi)發(fā)經(jīng)理的交流，另外客戶經(jīng)理也許與涉眾交互，開(kāi)發(fā)經(jīng)理與分析員交互.

圖1 協(xié)作圖

3 協(xié)作軟件需求產(chǎn)生

軟件需求開(kāi)發(fā)的最終制品是軟件需求規(guī)格說(shuō)明.IEEEstd-830推薦規(guī)格說(shuō)明書(shū)的章節(jié)組織和在規(guī)格說(shuō)明書(shū)里應(yīng)該包含什么.大多數(shù)需求分析采用SRS模板作為軟件需求規(guī)格說(shuō)明的章節(jié)結(jié)構(gòu).它包含幾個(gè)部分：引言、功能需求、非功能需求和詞匯表.

所有的涉眾分別寫他們自己的需求，一旦所有的涉眾完成他們的需求書(shū)寫，協(xié)作軟件需求將會(huì)按照簡(jiǎn)化的SRS格式被生成.涉眾使用需求編輯服務(wù)在協(xié)作平臺(tái)上書(shū)寫他們自己的需求.通常，需求被分成兩類，包括功能需求和非功能需求.決定需求的種類有三種情況，首先，因?yàn)檫@種需求非常明顯地屬于功能需求還是非功能需求，涉眾在沒(méi)有分析員的幫助下可以決定需求的種類.第二，需求不是很明顯能判斷屬于哪類需求，既使這樣，涉眾仍能決定需求的種類.然后，分析員給出涉眾所寫的需求種類的建議.最后，涉眾很難判斷需求的種類，涉眾僅寫下需求不決定需求的種類.決定需求的種類的任務(wù)由分析員完成.

考慮到非功能需求有兩類.一類是全局性的，限制適用整個(gè)系統(tǒng).對(duì)于局部性的非功能需求，限制只是作用在系統(tǒng)一些部分.功能需求和非功能需求的排列是基于局部和全局的屬性上的.對(duì)于軟件需求開(kāi)發(fā)進(jìn)展的監(jiān)控，可以使用一個(gè)簡(jiǎn)單的方法.即在涉眾參與的基礎(chǔ)上，完成需求編寫的涉眾的比例.因此，按照這個(gè)比例，可以意識(shí)到目前在協(xié)作平臺(tái)上的軟件需求開(kāi)發(fā)進(jìn)度.實(shí)際上，如有必要，可以調(diào)整每個(gè)人的責(zé)任.

4 協(xié)作軟件需求開(kāi)發(fā)過(guò)程

需求工程和過(guò)程涉及到捕獲客戶的需求.本文提出了在協(xié)作環(huán)境下的開(kāi)發(fā)軟件需求的協(xié)作軟件需求開(kāi)發(fā)過(guò)程.協(xié)作過(guò)程由六個(gè)活動(dòng)組成，包括建立順暢的通信途徑、角色分配、角色分配驗(yàn)證、涉眾編寫、分析員評(píng)論和SRS產(chǎn)生.另外，活動(dòng)也許產(chǎn)生一些制品，包括初始需求或精化需求、評(píng)論、最終的協(xié)作需求規(guī)格說(shuō)明.

完整的協(xié)作軟件需求開(kāi)發(fā)過(guò)程如圖2所示.活動(dòng)的詳細(xì)說(shuō)明如下：

（1）建立通信途徑活動(dòng).需求獲得成功，先要建立需求獲取所必需的通信途徑，即在其它角色之間建立良好的溝通方式.

（2）角色分配活動(dòng).這個(gè)活動(dòng)的主要任務(wù)是為將要進(jìn)行的協(xié)作軟件需求開(kāi)發(fā)做準(zhǔn)備.客戶和開(kāi)發(fā)秘書(shū)互相討論洽談.然后決定在需求開(kāi)發(fā)的過(guò)程中涉及到的角色.

（3）角色分配驗(yàn)證活動(dòng).如果角色分配是足夠的，這個(gè)活動(dòng)停止.如果有沖突或不合適，有必要返回到前一步.如果不是，這個(gè)活動(dòng)完成，進(jìn)入下一活動(dòng)涉眾編寫.

（4）涉眾編寫活動(dòng).第一次進(jìn)入這個(gè)活動(dòng)，涉眾寫出他們自己的需求，這次不但產(chǎn)生了初始的需求，而且進(jìn)入下一活動(dòng)-----分析員評(píng)論.如果這個(gè)活動(dòng)第一次沒(méi)完成，將會(huì)需要請(qǐng)求和評(píng)論作為輸入.

（5）分析員評(píng)論活動(dòng).這個(gè)活動(dòng)需要涉眾書(shū)寫的需求作為輸入.如果需求足夠完整，分析員會(huì)給涉眾有用的評(píng)論.如果需求沒(méi)有完成，會(huì)返回到上一活動(dòng)涉眾編寫.否則，將進(jìn)入下一活動(dòng)，協(xié)作軟件需求產(chǎn)生.

（6）SRS產(chǎn)生活動(dòng).這個(gè)活動(dòng)需要精煉的需求作為輸入，將會(huì)產(chǎn)生最終的協(xié)作需求說(shuō)明書(shū)制品.然后，進(jìn)入下一階段作需求驗(yàn)證.

圖2 協(xié)作軟件需求開(kāi)發(fā)過(guò)程

5 結(jié)論和未來(lái)工作

從涉眾正確、高效獲取需求一直是重要而且困難的任務(wù).除了技術(shù)方面，也應(yīng)考慮領(lǐng)域知識(shí)方面，由有許多不同背景的人員參加軟件項(xiàng)目，這些人之間的高效交流非常重要.過(guò)去，訪談、觀察用戶操作流程、組成聯(lián)合小組、用例、原型是獲取客戶需求的常用方法.但花費(fèi)時(shí)間太多.由于高速網(wǎng)絡(luò)的出現(xiàn)，可以通過(guò)網(wǎng)絡(luò)與其他人交流.相似的，可以在網(wǎng)絡(luò)環(huán)境下誘導(dǎo)出客戶的需求.本文提出基于網(wǎng)絡(luò)的環(huán)境中使用協(xié)作方法開(kāi)發(fā)軟件需求，在協(xié)作平臺(tái)上定義了七種角色：客戶秘書(shū)、涉眾、客戶經(jīng)理、開(kāi)發(fā)代表、分析員、開(kāi)發(fā)經(jīng)理、協(xié)調(diào)者.這些不同的角色在網(wǎng)絡(luò)環(huán)境下同時(shí)執(zhí)行需求編寫、審查、評(píng)論等任務(wù).不同的角色有不同的任務(wù).基于協(xié)作方法，在協(xié)作平臺(tái)上有幾種角色關(guān)系.為了到達(dá)協(xié)作工作目的，平臺(tái)提供了幾種協(xié)作服務(wù)以滿足協(xié)作工作的需要.所有的涉眾完成了他們的需求編寫后，綜合的軟件需求文檔將會(huì)產(chǎn)生.

交流和合作在軟件開(kāi)發(fā)需求階段是最重要的因素.把協(xié)作機(jī)制放入軟件需求開(kāi)發(fā).通過(guò)協(xié)作機(jī)制，人們互相協(xié)作開(kāi)發(fā)軟件需求.除了軟件需求開(kāi)發(fā)，把協(xié)作機(jī)制應(yīng)用到軟件開(kāi)發(fā)的其它工作也是有可能的.例如，把協(xié)作機(jī)制應(yīng)用于項(xiàng)目管理和監(jiān)督及系統(tǒng)分析和設(shè)計(jì)，最終的目標(biāo)是為方便軟件需求開(kāi)發(fā)，系統(tǒng)分析、系統(tǒng)設(shè)計(jì)、驗(yàn)證、項(xiàng)目管理等開(kāi)發(fā)基于網(wǎng)絡(luò)的平臺(tái).本文進(jìn)一步的工作是開(kāi)發(fā)協(xié)作項(xiàng)目管理監(jiān)督機(jī)制.

[1]程勇.從面向?qū)ο蟮矫嫦蚰繕?biāo)的需求分析[J].計(jì)算機(jī)科學(xué)，2001，28（12）：113.

[2]錢樂(lè)秋，趙文耘，牛軍鈺.軟件工程[M].北京：清華大學(xué)出版社，2007：47-48.

[9]陳曉樺.需求分析與獲取的方法學(xué)和技術(shù)[J].計(jì)算機(jī)應(yīng)用，1995，15（2）：20.

[3]Darimont R,va Lamsweerde A.Formal refinement patterns for goal-driven requirements elaboration[C].In Proceedings of Fourth ACM SIGSOFT Symposiumon the Foundations of Software Engineering,1996:179-190.

[4]Van H I,va Lamsweerde A.Goal-oriented requirements animation[C].In Proceedings of 12th IEEE International Requirements Engineering Conference,2004:203-213.

[5]van Lamsweerde A.Goal-oriented requirements engineering:A guided tour[C].In Proceedings of the 5th IEEE International Symposium on Requirements Engineering,2001:249-262.

[6]Bolchini D,Paolini P.Capturing web application requirements through goal-oriented analysis[C].In Proceedings of the 5th Workshop on Requirements Engineering,2002:16-28.

[7]Bolchini D,Paolini P,Randazzo G.Adding hypermedia requirements to goal-driven analysis[C].In Proceedings of the 11th IEEE International Requirements Engineering Conference,2003:127-137.

[8]Towards modelin,E Yu.support for early-phase requirements engineering[C].In Proceedings of the 3rd IEEE International Symposium on Requirements Engineering,1997:226-235.

[10]Chung L,Nixon B.Non-Functional Requirements in Software Engineering[M].Dordrecht:Kluwer Publishing,2000.

[11]Mylopoulos J,Chung L,Nixo B.Representing and using non-functional requirements:A process-oriented approach[J].IEEE Transactions on Software Engineering,1992,18(6):483-497.

[12]Kruchten P.The Rational Unified Process:An Introduction[M].New Jersey:Addison-Wesley,2000.

[13]Fowle.M.UML Distilled[M].New Jersey:Addison-Wesley,2004.

[14]Jacobson I.Object-Oriented Software Engineering:A Use Case Driven Approach[M].New Jersey:ACM Press,Addison-Wesley, 1992.

A Method Based on Role and Collaboration for Capturing Software Requirements

GUO Hui，DONG Rui-zhi
(School of Computer Science and Engineering,Changshu Institute of Technology,Changshu 215500,China)

Capturing customer’s desired requirements precisely is a necessary task.Many efforts are made in requirement engineering.The broadly used approaches are goal-oriented approach,object-oriented approach, team-oriented approach,etc.A collaborative method and process to develop software requirements are presented in this paper.Many roles are defined and each of the roles performs a number of tasks of requirements writing, reviewing and commenting at the same time.Different roles are responsible for different tasks.A number of role relationships are proposed.The platform provides several collaborative services to satisfy the needs of developing requirements of a software system.After all stakeholders finish their authoring of requirements,the integrated software requirements document will be generated.

software engineering;requirement engineering;object-oriented;role;collaboration

TP311.5

A

1008-2794（2012）04-0115-05

2011-12-10

郭輝（1969—），男，江蘇徐州人，講師，研究方向：軟件工程.