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

郭輝，董瑞志

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

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

郭輝，董瑞志

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

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

軟件工程；需求工程；面向對象；角色；協作

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

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

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

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

1 角色和角色關系

軟件系統開發是一個需要協作的工作，特別是軟件需求開發階段.在軟件需求開發中涉及到一些人.因此，需定義幾種角色和角色關系.

1.1 角色

在多角色協作平臺上把角色分成三類，一類是客戶端，一類是系統開發端，一類是中間協調者.多角色協作平臺中，共定義7種角色，客戶端有客戶秘書、涉眾、客戶經理，系統開發端有開發秘書、分析員、開發經理，還有協調者.不同的角色有不同的特征和任務.

協調者：負責建立順暢的通信途徑.

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

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

客戶經理：與開發經理和涉眾交流，另外，客戶經理負責管理監督來自所有涉眾的需求.

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

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

開發經理：與系統分析員和客戶經理洽談，另外，開發經理負責協作軟件需求的產生.

1.2 角色關系

1.2.1 （客戶經理/客戶秘書/涉眾/開發秘書/開發經理/分析員）——協調者

這種關系涉及到所有角色，協調者在其它角色之間建立良好的溝通方式.

1.2.2 秘書-秘書洽談角色關系

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

1.2.3 涉眾-分析員協作角色關系

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

1.2.4 （客戶經理/涉眾）—開發經理角色關系

這個角色關系可表示為：涉眾-------------客戶經理----------開發經理.

由三種角色構成.主要的交流是客戶經理和開發經理之間，另外，開發經理、客戶經理也可與涉眾交流，這時，客戶經理可被看作是涉眾和開發經理間的橋梁.

1.2.5 客戶經理—（開發經理/分析員）角色關系

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

1.2.6 （客戶經理／涉眾）－（開發經理／分析員）的角色關系

這個角色關系為：涉眾----------客戶經理----------開發經理---------分析員.

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

1.2.7 客戶經理－開發經理角色關系

這種關系為：客戶經理----------開發經理.

不同的涉眾分別完成各自的需求后，協作的軟件需求就會產生.然后，執行協作軟件需求的驗證.客戶經理和開發經理共同完成驗證.

2 協作機制

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

2.1 協作服務

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

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

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

協作驗證服務：提供需求驗證的方法和環境.客戶經理和開發經理互動協作驗證需求規格說明.

2.2 協作模式

考慮到軟件需求的發展，需要提高軟件項目人員之間的交流，因此特別強調在基于網絡環境下的人員間的合作.下面介紹在協作平臺上的幾種普遍協作模式.

2.2.1 單一對等協作

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

2.2.2 多對協作

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

2.2.3 單一中心協作

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

2.2.4 多中心協作

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

圖1 協作圖

3 協作軟件需求產生

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

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

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

4 協作軟件需求開發過程

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

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

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

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

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

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

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

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

圖2 協作軟件需求開發過程

5 結論和未來工作

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

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

[1]程勇.從面向對象到面向目標的需求分析[J].計算機科學，2001，28（12）：113.

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

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