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

郭輝，董瑞志

（常熟理工學院計算機科學與工程學院，江蘇常熟 215500）

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

郭輝，董瑞志

（常熟理工學院計算機科學與工程學院，江蘇常熟 215500）

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

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

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

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

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

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

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

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

1.1 角色

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

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

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

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

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

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

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

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

1.2 角色關(guān)系

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 協(xié)作機制

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

2.1 協(xié)作服務

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

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

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

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

2.2 協(xié)作模式

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

2.2.1 單一對等協(xié)作

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

2.2.2 多對協(xié)作

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

2.2.3 單一中心協(xié)作

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

2.2.4 多中心協(xié)作

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

圖1 協(xié)作圖

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

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

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

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

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

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

完整的協(xié)作軟件需求開發(fā)過程如圖2所示.活動的詳細說明如下：

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

（2）角色分配活動.這個活動的主要任務是為將要進行的協(xié)作軟件需求開發(fā)做準備.客戶和開發(fā)秘書互相討論洽談.然后決定在需求開發(fā)的過程中涉及到的角色.

（3）角色分配驗證活動.如果角色分配是足夠的，這個活動停止.如果有沖突或不合適，有必要返回到前一步.如果不是，這個活動完成，進入下一活動涉眾編寫.

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

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

（6）SRS產(chǎn)生活動.這個活動需要精煉的需求作為輸入，將會產(chǎn)生最終的協(xié)作需求說明書制品.然后，進入下一階段作需求驗證.

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

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

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

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

[1]程勇.從面向?qū)ο蟮矫嫦蚰繕说男枨蠓治鯷J].計算機科學，2001，28（12）：113.

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

[9]陳曉樺.需求分析與獲取的方法學和技術(shù)[J].計算機應用，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—），男，江蘇徐州人，講師，研究方向：軟件工程.