聊天活動到場10位嘉賓，他們分別是（從左往右）：潘加宇（UMLChina）、殷志梅（東方通科技）、張皖秋（東方通科技）、Kristian Persson（Telelogic）、任群力（Telelogic）、于波（賽柏科技）、青潤（豐元信）、李峻（西門子）、林治宇（天融信）、吳浩剛（天融信）�，F場討論氣氛熱烈。
嘉賓介紹
主持人：首先歡迎各位參加CSDN和Telelogic共同舉辦的需求管理在線沙龍活動，我們這次活動的主題是“探索需求”，活動分為三個環節，分別就需求的啟發、需求的定義和需求的管理進行討論，活動采用圓桌論壇和在線直播的方式，網友可以進入聊天室與現場互動，活動還邀請到了來自Telelogic、天融信、北京東方通科技有限公司、西門子等十位需求管理專家以及來自各行各業需求管理的工程師，下面有請各位嘉賓做一下自我介紹。
任群力：很榮幸今天來到CSDN來參加需求管理沙龍活動，也很高興和業內的朋友見面。作為需求管理的領先方案的提供商，很愿意提供給客戶解決方案。我是Telelogic的北方區負責人，負責Telelogic 中國公司在北方地區運作的所有事宜，包括人員規劃、市場開發、銷售和客戶技術支持工作。希望有機會與大家交流，謝謝。
Kristian Persson：我叫Kristian Persson，中文名叫佩爾森，我在北京工作，是Telelogic需求管理DOORS的產品經理，主要是負責亞太地區，主要是東亞部分，比如韓國、日本、中國。我還負責Telelogic需求管理解決方案的教育、培訓工作。在過去的6年中，我一直致力于軟件行業從需求捕獲、分析、設計、實現直到測試的軟件生命周期所有階段的工作，對系統和軟件分析、設計和測試的多種過程、方法及工具有著一定的經驗。
于波：大家好，我是于波，是北京賽柏科技公司高級咨詢師，北京理工大學軟件學院客座教授，今年年底或明年年初會成為賽柏科技CMMI準主任評估師。我們公司主要為中國軟件和IT企業做軟件工程CMMI參考項目的過程改進，負責CMM、CMMI等模型與標準、軟件工程、質量管理和項目管理等方面的培訓、咨詢和評估工作，為中國軟件在世界上的崛起貢獻出我們的微薄之力。
白慧冬：我手上拿的這本書叫《需求工程》，和我寫的那本書《軟件工程之全程建�！返牡谝徽旅忠惨粯�，也叫“需求工程”。需求是整個軟件開發過程的源頭，所以我把需求看得很重要。我目前是豐元信科技咨詢公司首席顧問，主要面向國內軟件企業提供工程開發方面的咨詢服務。我還是CSDN軟工版大版主，一個在不斷摸索實踐的國內軟件工程方法和技術的親歷者。
李峻：大家好，我是李峻，我是代替我的同事——西門子智能手機研發中心需求管理經理黃謙來參加這次活動的。我是西門子手機研發中心硬件驅動部門、需求管理DOORS數據庫的管理員，我也是我們研發中心軟件流程管理項目組需求管理的其中一名Topic owner，負責相關的流程定義、文檔模板等等。我們公司用了Telelogic公司的DOORS工具來做目前的需求管理。我們產品開發的管理，也在使用Telelogic公司的DOORS工具。很想和大家分享一下項目和管理中遇到的問題。
林治宇：大家好，我叫林治宇，來自北京天融信。天融信是一家做網絡安全產品的公司。我是天融信公司CMMI過程改進和QA主管，主要負責CMMI的組織推廣和策劃工作，并曾組織多家企業實施并通過CMM2級、3級，CMMI2級評估。很高興與大家交流，謝謝大家。
吳浩剛：大家好，我是天融信公司質量部經理，曾主持過多家企業的ISO9000/CMM/CMMI實施和評估。需求在產品開發階段非常重要，今天有機會參加這樣的活動感到非常的高興，謝謝！
張皖秋：大家好，我叫張皖秋，來自于北京東方通科技有限公司，目前擔任SEPG組長、SQA經理，主要負責軟件質量的改進的工作。今天非常高興參加這樣的座談會議，希望在這里跟大家交流和探討，需求非常重要，以需求為驅動，使項目改進能夠得到一個更好的提升。
殷志梅：大家好，我是北京東方通科技有限公司產品經理殷志梅，主要是負責使用Telelogic DOORS進行需求收集與整理、需求分析，參與產品的設計，跟蹤需求的實現以及需求方案與測試之間的映射。我們公司采用Telelogic的DOORS工具來做需求管理。有些困惑，希望和大家進行交流。
潘加宇：我是UMLChina的潘加宇。一直從事一些軟件技術難題的研究，也為不少軟件企業提供過上門的咨詢和培訓服務，在座的西門子移動和北京東方通科技有限公司都是我們服務過的客戶，希望今天在這里得到需求方面的寶貴經驗。
你對需求工作是否重視？
主持人：談到需求，我想了解一下大家對需求的態度是怎樣的，所以現場做一個小的調查。我這里有一個調查問題：下面哪一句話比較符合您的情況，我按照A、B、C、D說一下，然后大家舉一下手。A項，我認為需求不重要；B項，我知道需求重要，但不知道為什么重要；C項，我知道需求為什么重要，但不知道怎么去做；D項，我知道需求為什么重要，也知道怎么去做。我想知道大家選哪項。
看來大家選D項的比較多。
我們這個問題同樣在網上做了調查，我們可以看一下網上調查的結果。選擇“我知道需求為什么重要，但不知道怎么去做”，也就是選C項最多。大家可以就這個結果做一個大致的分析。
潘加宇：我覺得這很正常，知道需求為什么重要，他不知道也得知道，因為事實非常的簡單，他要搞不定這個需求，將來客戶那里馬上就得返工，所以知道需求重要。
我們現在很多團隊知道需要重要，也想改進，但實際上很多時候改進不了，就是因為不知道怎么去改進，不知道怎么去做。比如我們經常說一定要做好需求，各個團隊都有這樣的想法，很可能在整個工作量當中也為安排了時間，實際上真正去做的時候，不知道怎么去做，去客戶那里找誰，問什么問題，怎樣做調查，這些技能都沒有掌握，去了以后不知道怎么去做，結果就不了了之了，干脆這個時間就去編代碼。
為什么很多開發急于馬上進入設計和熟悉的階段，因為是他熟悉的，也是會做的。因為做熟的東西，做的時候很舒服。有些需求沒有掌握，知道重要，不知道怎么做，最終做需求的時間很容易虛度掉，或者急急忙忙做開發和設計。所以，現狀是非常的符合我們現在開發的情況。
需求工作流占你的整個項目工作量的比例有多大？
主持人：選擇D項的也很多，就是“我知道需求，為什么重要，也知道怎么去做”。就像李峻所提到的一樣，有很多人知道怎么去做，但做的情況下未必按照正確的方法做，所以選這一項也很多。但盡管選擇這一項，在實際的需求工作當中，也會經常面臨很多問題。我們下面進入第一個話題，需求是怎么來啟發的，怎樣來從你的客戶那里獲得需求？
主持人： 首先請問大家一個問題，各位在做需求工作的時候，你的需求工作流在你整個項目中所占的比例大概有多少？
林治宇：我舉一下我們一個產品的例子，我們是根據市場行業和用戶對手的信息總結的一些產品。我們最后統計了一個數字，需求工作占到我們項目的8％－10％。
Kristian Persson：剛才聽到8％－10％的需求，應該說這是非常合理的數字，這是國際上大多數公司大概也是這樣的數字，無論是做軟件還是做什么的，都是這樣的。
李峻：我想問一下Kristian Persson，還有壓縮的可能性？如果有好的一些工具的話，能否再縮短工作量嗎？
Kristian Persson：10％一般是比較正常的數字，如果再壓縮的話，可能比較困難。我指的10％并不是一開始需求的階段，而是與整個活動相關的需求都包括。有的項目需求花的時間更多，就是因為在有問題的時候，有時候不能確定需求，工作量達到了40％－50％。
李峻：我認為其實和客戶的交流也很重要，在第一步需求搜集這一塊。如果你的客戶很清楚他自己的需求，可以縮短很多時間和工作量，達到大家一致需求的起點。
誰負責捕獲需求？
主持人：我們再做一個調查：在各位的公司里，都是由誰來做捕獲需求？A.有專門的需求工程師負責捕獲需求。B.由面向客戶的市場部人員；C.負責設計和實現的人員同時也做需求；D.沒有人。
主持人：我們同時再看一下網上調查的情況，選擇C項的占大多數，將近有60％。請大家分析一下產生這個現狀的原因是什么？
白慧冬：對這個結果需要指出的是，負責設計和實現的人員同時做需求，并不是所有做編碼的人都去捕獲需求，而是有一部分人在一段時間做，而并不是全部的編碼團隊都去做捕獲需求。所以會出現這個結果，負責編碼的人同時做需求比較常見。
潘加宇：現在做項目的公司，單獨設立需求工程師職位的，比較少。更多的情況是，部門經理帶著骨干做調研需求，其他人做開發。對兩種人的思維要求是不一樣的。做需求的要有集成思維，把問題集成起來去思考；而程序員要有分解的思維，問題已經給出來了，要分解成對象，分解為模塊，就可以搞定它。所以一個公司做設計的人專門做需求或者做調研，我認為這是非常有必要的。如果對產品有更高的要求，對自己軟件有更高要求的話，這應該是一個比較好的方向。
于波：剛才白慧冬和潘加宇提到這個問題，跟目前國內軟件業管理流程上還不算很規范是相關的，這個調查結果是很正常的。因為項目管理也不是做純管理，需要有技術的背景，核心工程師和客戶溝通需求，然后他們項目里面逐步把這些需求做實現。由于管理規范了，肯定會有一些專職人員，專門設了這樣的職位以做需求為主。潘加宇說得也有道理，需求工程師需要在整體上把握客戶的需求，無論產品也好還是功能開發也好，完全由做設計和編碼的人來做，他們是很難站在項目整體的高度來考慮客戶所有相關人員的需要、需求、期望以及對未來還要需要什么，這樣也會對未來的需求變更帶來一些潛在的影響。
林治宇：對剛才的60％這樣的結果，我有一個看法：并不是公司實力特別強才有資源設立專門的需求工程師的人員，而是公司要認識到這個資源對產品的重要性，才會設這個職位。
主持人：做需求的人，都是離市場比較近一些，尤其是在產品型公司里，真正去捕獲需求的人是做市場的人，是面向客戶的市場人員來負責捕獲需求。想借此問一下Telelogic，你們接觸的客戶，這種情況多嗎？
Kristian Persson：這又是一個溝通的問題，各自干各自所擅長的事情，讓編程的人集中精力做開發，真正做需求的人，往往是會做市場的人。因為他們與客戶接觸緊密，更加了解客戶的需求。由他們反饋給開發人員的需求，更加準確和直接。
李峻：我們公司真正負責捕獲客戶需求的工作也是主要由市場部人員去做，但并不是直接將這些需求轉給開發部。我們成立了一個需求管理小組，人員并不是很多，有一個需求管理負責人手下帶了幾個需求工程師，他們主要的職責，其實相當于市場部人員和開發人員的一個接口。市場部人員收集來的這些需求，基本上作為原材料提供給需求工程師。需求會從最終的用戶、運營商當中得到，會有一個非常龐大的文檔過來，但不會從技術方面做任何考慮，所以需要需求工程師對這些零散和龐大的需求進行整理和分類。
主持人：你們對需求管理小組的要求又是怎樣的呢？小組成員都做哪些工作？
李峻：我們的工程師具有一定的技術背景，因為他們屬于我們的研發中心，并不屬于市場部門，是我們研發中心下面的一個組，和我們的市場管理人員接觸更多一些。我們開發人員不需要和市場部爭論哪些事情做得到還是做不到，而是由需求工程師來做，把需求一層一層進行分解，由需求工程師把客戶沒有任何技術背景的需求更詳細分析出來，這樣我們的開發人員就可以在純技術領域下思考這個需求。我認為需求管理組在研發中心還是起到作用的，最初設立這個需求管理組，也是考慮到需求環節是研發中的一個弱項，之后才建立了需求管理組，現在收到了很多成效。
于波：我想大家會達成共識，首先由市場人員捕獲最原始的需求，這是用客戶的語言、客戶的業務和流程來做的，內部還有需求分析人員，把客戶需求進行整理，細化為產品或者軟件的需求，還要細化一些產品的構件以及具體構件的接口等一些潛在的需求。原始需求由市場和客戶人員做到，剛才Kristian Persson先生也提到了，因為和客戶打交道最多，最了解客戶心里想什么。
另外，對于需求工作，有兩方面的說法，一是做需求開發，即前面說的是需求引導，還有需求管理，他們可能是一個角色來做，也可能不是一個角色來做。另外，除了前面市場人員外，很多規范企業會有專門系統分析人員，這些分析人員不一定是銷售和市場人員。例如，電力行業人員，請電力行業非常了解的人來溝通最原始的需求，然后和公司里面負責產品需求的人來計劃產品需求，一定要考慮企業的特點，剛才也提到企業投了什么樣的資源來從事這個工作，是資深人員還是沒有經驗的人員，這要根據自己的情況來做，把幾個方面的信息和相關人員結合在一起，大家進行溝通，然后再往下來做可能會好一些。
歐陽璟：剛才聽各位發言，有一個共識，需求管理應該是單獨抽出來做的。但有時會出現一個問題，現在大多數企業沒有資源專門成立部門做這種單獨的需求，這樣就導致了市場人員、或編碼人員、或設計人員來兼做需求�，F在有一個問題，哪些角色更加適合來做這樣的工作？
Kristian Persson：Telelogic公司是一個中等規模的公司，如果單獨拿一個產品線來說，和一些中小型公司是類似的，我們每個產品都有一個產品經理，這個產品經理雖然屬于研發部門，但是他們會到市場去做調研，看需要什么產品，看競爭情況是怎樣的，然后把這些信息溝通完了以后，跟這些開發人員一起來商量，哪些需求有實現的必要性，哪些需求的實現更加重要。所以，產品經理這樣的角色是比較適合的。
吳浩剛：一個需求做好的話，必須有一個角色完成，不同階段要有不同的需求。比如從用戶需求這個角度，有內部用戶需求和外部用戶需求，市場人員一般捕獲的是用戶明示的要求，如果是潛在要求的話，必須要用技術背景來捕獲，否則需求的實現工作就會很難。
主持人：剛才提到我們在捕獲需求的時候，一個很重要的角色就是產品經理，我想問一下殷志梅，你在東方通擔任產品經理的角色，你的角色定位是不是也是捕獲需求，把需求的一些相關的內容轉達給開發人員呢？
殷志梅：我現在在東方通的職責就是管理需求，也就是公司內部的需求，根據市場上一些相關軟件和產品的功能，在公司內部收集一些需求。這些需求，如果他們認為可以做就可以做，我們會進行討論和評審，決定到底做不做。
李峻：市場部成員的技術背景都不強，所以必須有一個需求管理的團隊來支持他們，更多偏向于市場部，由他們轉過來的市場部信息，經過需求工程師的把關，再轉給開發部門，否則，開發部門的人員就要抗議了。
殷志梅：我以前是做開發測試的，我個人技術方面的背景比較強，包括和開發人員溝通比較強一些，我很容易把他們的意思轉換為我們的產品需求。尤其中國的市場，有時候忙于簽單，用戶說不需要這樣需求，就立刻答應了，就逼著工程人員把這個需求實現了。
網友提問：“做需求的時候，在工作期間有沒有淡季的說法呢？”
殷志梅：沒有什么淡季，屬于持續的過程。因為產品是一個版本一個版本在升級。
于波：技術在不斷的升級，市場需求也在變化。本身軟件市場的競爭強度很大，不可能停下來。
歐陽璟：針對產品做需求這塊，這個版本做完了以后，相對一段時間會比較淡一點，或者這個版本做完以后做下個版本需求，那時候在做編碼的時候，可能這邊相對輕松一些。
Kristian Persson：如果在一個良好的需求管理流程過程當中，往往對需求管理都是很忙碌的，開發人員在目前管理的同時，也在看下一個版本，甚至到以后的幾個版本。
殷志梅：一般是那個產品在編碼，下個需求我們就在做，需求也會增加，沒有什么淡季的說法，是一直持續的。
你的“探索需求”的過程中，會經常使用哪些方法或技能？
主持人：下面我要問一下大家，在捕獲需求的時候，經常使用哪些方法和技術？我有幾個選項：A.文檔研究 B.問卷調查 C.訪談 D.觀察 E.研究競爭對手 F.原型 G.開會與協商。
吳浩剛：在天融信，我們主要用到的方法是訪談，還有就是做原型，因為原型可以直接讓客戶看到產品大概是什么樣的，訪談也很重要，因為尤其是對于做需求的公司來說，除了某些業務背景之外，客戶交流這塊也是有相當經驗的。
李峻：我相信這些方法在西門子都用過，比如文檔研究，會針對運營商的需求，溝通會比較多一些。每個運營商都會主動提供他們的需求文襠給我們，當然是格式不太一樣，問卷調查也會有，比如提供統一的格式給他們做一些選項。研究競爭對手更是我們必須做的事情。原型也是這樣，在開發的時候，不同階段都會提供原型給經銷商和開發商，咨詢有沒有改進的建議，我想這些方法在整個開發流程里，在不同階段有它的重要性以及更大好處。
Kristian Persson：Telelogic有幾種調研的方法，其中很重要的就是領導者委員會，比如我們做產品，用一百個用戶形成一個團隊，像這個大的用戶每年都有一個活動叫在一起，然后共同談論問題，需要什么新的功能在產品里面實現，他們也相互交流。第二，對于競爭對手分析也是要做的。第三，在技術支持過程當中，如果發現了問題，我們是需要解決然后再研究下一個版本。
另外，對于技術演變來說，比如有一個新的平臺或者新的版本的話，我們這個版本也必須支持新的平臺。在做產品的時候，在生命周期的時候，我和其他產品相互結合的部分要進行改進，要在新的產品實現�？偟膩碚f，剛才提到調研的幾點，基本上每一點都涉及到不同的特色。我們也做產品原型，可能是對于一些特殊客戶的定制，如果比較成功的話，自然而然也會對我們的產品更加的感興趣。
殷志梅：可能和吳浩剛所說的調研方法比較相似，調研也有，原型也有，對于有些特殊需求的客戶一般都用原型，我們會進行上門服務。技術支持也有一些，再有就是技術的演變會促進產品升級。
主持人：我們可以看一下網上調查的結果，了解一下現在大家做需求的時候都采用哪些技術，我們可以看到，選擇訪談的人占的比例是最大的，其次是開會協商和文襠研究，原型也是不可忽視的環節。我想請問一下潘加宇，你對這個結果怎么分析呢？
潘加宇：訪談最多，應該是很自然的。要做需求，就要問你，你想要什么。當然訪談也有技能，比如找的人對不對，問問題的技巧對不對。如果往往找人找錯了，比如做工廠系統內的，你就要訪談工人，不要訪談工廠主任。如果要做初中生的軟件，你就找初中生進行訪談了。還有問卷調查也是這樣，如果你不做問卷調查的話，得出的東西是不對的，訪談也是不全面的。另外，訪談之前要研究文襠，對于一些業務知識和業務要懂，這是聯系在一起的。
訪談完了以后，可能不同涉眾有不同的需求，也可能有利益沖突，比如營業部門希望越快越好，維修部希望越慢越好，發生沖突就要開會研究起來，但這都是緊密聯系在一起的。像原型的話，也是訪談當中要用到的。還有就是競爭對手，尤其是現在做產品來說，研究競爭對手是首要的，已經不是訪談為中心了。從研究競爭對手出發的話，如果你研究的話，產品可能賣不出去了。市場上有一百種產品，都是滿足客戶的要求，但為什么要買你的呢？要從競爭對手想，才能找到自己的位置，所以這非常的重要。
像剛才Kristian Persson先生所說的，我覺得很有意思，這幾次做活動的話往往是需求方面，其實有很多產品，有建模的產品等，但都是來做需求，為什么呢？因為這是強項，研究競爭對手的話，就要有一個結果，比如我就做DOORS，要鮮明突出出來，很多需求都是這樣出來的。對于客戶的要求，比如說TAU建模工具不好，是否就要研究在這方面呢？往往競爭是突出一個長處，有特點，給大家造成影響，所以這一點是研究競爭對手是非常重要的。
我們做產品的時候成功與失敗，這方面是非常重要的。有時候很容易找錯對手，有時候經營公司非常的盲目，不自覺的認為自己沒有競爭對手，像今年二月份我去上海的時候，我有一個朋友做服務的公司，我問他競爭對手是誰？他說沒有競爭對手。我說為什么？他說這里已經壟斷了，政府讓我們做，別的地方不讓做。后來我跟他講輸入輸出的問題，他就了解到原來還有競爭對手。如果現在做一個產品，東方通科技的競爭對手是誰呢？這應該要觀察，本來有些人要買東方通科技產品，但沒有買，我們就要知道競爭對手是誰呢？如果有這個需求，而沒有買，去干什么呢？他去買防火墻和加密軟件。有時候不買DOORS，而買其他的產品代替，我認為這都是競爭對手，這都是需要考慮的。
主持人：青潤，你在你的那本書當中也談到需求，是否可以談一下你對需求捕獲方法的認識？
白慧冬：需求就是要有捕獲，沒有捕獲怎么會有后援的過程。在我那本書談到需求，往往做需求的時候，尤其是做工程，我本人做工程比較多，產品反而做得比較少。我先說一下做工程軟件，第一要做討論，然后收集一些初始想法，第二要研究內部文檔，你訪談的過程中要收集相關資料，然后就搞研究，搞研究的時候要出一些輔助的東西，那就是原型，原型之后，下一步還是訪談，原型之后出一個版本，就是客戶基本可用的，但不是完全可用，在用戶用的時候再技術訪談。問卷調查，做工程的很少用，發給誰呢？沒有人接手，不像做手機，西門子運營公司可以發給別人，而我們不行。比如做電信，幾個運營商，我發問卷調查，就幾個，我給他們發完了，實際上得到的結果也就那樣，沒有什么意義。
觀察方面比較少，因為工程軟件往往是內部獲得需求。當時我做的需求當時是電信內部提出的，本來要做ERP，后來由于宣布暫時停止，可以說生命周期得到的延長。
主持人：在CMM和CMMI當中，對需求部分的描述是怎樣的？與CMM和CMMI相比，你所咨詢的這些國內軟件企業在需求流程方面的差距有多大？
于波：之前提到捕獲需求的方法，提了自己的看法，工程也好，產品也好，首先方法上都討論過了，CMM本身模型提得比較早，1993年提出來的，從1987年開始研究，當時軟件工程發展到當時那個階段，對于需求捕獲，國內叫需求分析和需求開發，這種定義是在CMM三級產品工程里面一個活動，有分析、開發和客戶驗證的需求，就是一個活動。而CMMI就不一樣了，因為行業在發展，技術在發展，方法在發展，模型也在發展，把需求捕獲叫需求開發，這里面分得比較細，分為用戶的需求、產品的需求、產品構件的需求以及產品接口之間的需求，以及需求之間還有相互關系上要確認，跟設計和實現之間也是一個反復循環的階段來做的。
在國內來講，如果要做了CMM和CMMI的話，嚴格來講，和軟件工程上流行的一些方法和做的規程，達到的要求基本能達到，我們在咨詢的過程中，根據產品的形狀以及項目的特點、應用領域以及客戶的特點，來幫他選擇定義并細化一些需求捕獲過程中的規程和步驟，還有必要的重要的模板，每一層定義成什么樣的，還有捕捉方法里面，比如產品以及工程，都會做過一些調查。如果沒有做過的話，知道需求，但不是很清楚。另外就是時間的壓力很大，成熟不成熟呢？規范不規范化呢？他敢不敢做下來認真看這個需求，以及怎樣著手的話，他沒有時間來做，就做編碼，編碼的話就陷入一個混亂的狀態。
吳浩剛：現在國內公司做需求的方法和構成，CMM的要求還是有差距的。過去是用戶需求、產品需求，很多公司都沒有把它區分開。第二，一些公司做任務需求的時候，僅僅局限于外部需求，恰恰忘了內部的需求，一個產品要達到效益，還要考慮成本，在過去捕獲需求的時候，為了測試，要制造一些需求。為了讓成本降低，可能要做維護方面的需求。另外，在維護方面也要考慮需求方面。一個產品如果一開始考慮需求的時候，沒有考慮批量生產的話，到了后期可能就會影響到項目當中。
李峻：這些我們都有用，但是根據整個流程的不同階段來用，比如從市場過來的第一手的需求，是很簡單的需求列表。如果到了需求工程師分布下來以后，分到產品的話，可能就用到用例來表示產品的需求，再到下一層，比如產品里的模塊，模塊會有更詳細的圖，甚至用Telelogic公司的DOORS工具來做一些分析。我們是根據不同的階段來用的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
