1、需求工程及需求管理工具介紹V 1.0Marco Lee2012-09-04Contents一、需求工程綜述31）需求定義32）需求工程概述33）需求工程主要過(guò)程44）需求分析的特點(diǎn)45）需求開(kāi)發(fā)的十種常用方法56）需求建模方法57）主要概念區(qū)分61、項(xiàng)目范圍管理62、需求開(kāi)發(fā)、需求管理、項(xiàng)目范圍管理的區(qū)別和聯(lián)系7二、CMMI需求開(kāi)發(fā)過(guò)程71）基本概念72）需求調(diào)查方法83）CMMI需求分析過(guò)程9三、需求管理工具介紹121）Rational RequisitePro122）IBM Rational DOORS123）Borland CaliberRM144）Cloudtopo Topo14摘要需

2、求是研發(fā)團(tuán)隊(duì)工作的起點(diǎn)，很多研發(fā)團(tuán)隊(duì)的開(kāi)發(fā)過(guò)程混亂的源頭都在于需求管理沒(méi)有做好。項(xiàng)目失敗或嚴(yán)重超支的八個(gè)最重要原因中有五個(gè)都與需求相關(guān)：1) 不完整的需求；2) 缺乏用戶(hù)的參與；3) 不實(shí)際的客戶(hù)期望；4) 需求和需求規(guī)格說(shuō)明的變更；5) 提供許多不必要的功能。本文就有關(guān)需要的概念以及主流需求管理系統(tǒng)，進(jìn)行了論述。一、需求工程綜述圖 1-需求分析組成部分1）需求定義通俗的講，“需求”就是用戶(hù)的需要，它包括用戶(hù)要解決的問(wèn)題、達(dá)到的目標(biāo)、以及實(shí)現(xiàn)這些目標(biāo)所需要的條件，它是一個(gè)程序或系統(tǒng)開(kāi)發(fā)工作的說(shuō)明，表現(xiàn)形式一般為文檔形式。按CMMI軟件能力成熟度的定義，需求是開(kāi)發(fā)方和客戶(hù)方就系統(tǒng)未來(lái)所達(dá)到的功能

3、和質(zhì)量所達(dá)成的一致約定和協(xié)議。PMP定義，需求是指發(fā)起人、客戶(hù)和其它干系人的已量化且記錄下來(lái)的需要與期望。收集需求旨在定義和管理客戶(hù)期望。2）需求工程概述需求工程過(guò)程即需求分析活動(dòng)，以下統(tǒng)稱(chēng)為需求工程在整個(gè)系統(tǒng)開(kāi)發(fā)與維護(hù)過(guò)程中越來(lái)越重要，它貫穿于系統(tǒng)開(kāi)發(fā)的整個(gè)生存周期。上個(gè)世紀(jì)80年代中期，形成了軟件工程的子領(lǐng)域需求工程 (Requirement Engineering, RE) 。需求工程，是應(yīng)用已證實(shí)有效的技術(shù)、方法進(jìn)行需求分析，確定需求客戶(hù)，幫助系統(tǒng)開(kāi)發(fā)分析人員理解問(wèn)題，評(píng)估可行性，協(xié)商合理的解決方案、無(wú)歧義地規(guī)約方案、確認(rèn)規(guī)約以及將規(guī)約轉(zhuǎn)換到可運(yùn)行的系統(tǒng)時(shí)的管理要求。需求工程通過(guò)合適的

4、工具和符號(hào)系統(tǒng)地描述待開(kāi)發(fā)系統(tǒng)及其行為特征和相關(guān)約束，形成需求文檔，并對(duì)用戶(hù)不斷變化的需求演進(jìn)給予支持。需求工程是一個(gè)項(xiàng)目的開(kāi)端，也是項(xiàng)目建設(shè)的基石。需求工程的過(guò)程包括了需求開(kāi)發(fā)和需求管理兩個(gè)部分。整體需求工程過(guò)程在項(xiàng)目啟動(dòng)后開(kāi)始，進(jìn)行需求獲取、分析、規(guī)劃定義和需求驗(yàn)證，并進(jìn)行組織內(nèi)外的需求評(píng)審，以確定需求基線(xiàn)，并在需求發(fā)生變更時(shí)，重新進(jìn)行需求的獲取、分析、定義和驗(yàn)證評(píng)審，并對(duì)需求變更影響項(xiàng)進(jìn)行相關(guān)識(shí)別、風(fēng)險(xiǎn)應(yīng)對(duì)、修改和跟蹤，并對(duì)需求狀態(tài)和變化過(guò)程進(jìn)行統(tǒng)計(jì)分析和測(cè)量匯報(bào)。 需求開(kāi)發(fā)（RD，Requirement Development）指的是從問(wèn)題收集、分析和評(píng)價(jià)到編寫(xiě)文檔、評(píng)審等一系列產(chǎn)生需

5、求的活動(dòng)，這幾個(gè)階段的活動(dòng)可以是相互獨(dú)立和反復(fù)的，不一定非要遵循線(xiàn)性的順序。需求開(kāi)發(fā)講究的是用系統(tǒng)的方法獲取真正的全面的能實(shí)現(xiàn)的需求。 需求管理（RM, Requirement Management）則是與需求直接相關(guān)的活動(dòng)，即軟件項(xiàng)目開(kāi)發(fā)過(guò)程中控制和維持需求約定的活動(dòng)，主要包括：變更控制、版本控制、需求跟蹤、需求狀態(tài)跟蹤等工作。需求管理強(qiáng)調(diào)的是需求的確認(rèn)以及需求變更的控制，其目的是確保各方對(duì)需求的一致理解，管理和控制需求的變更，從需求到最終產(chǎn)品的雙向跟蹤。3）需求工程主要過(guò)程1） 需求開(kāi)發(fā)規(guī)程：分為需求獲取、需求分析、規(guī)格化定義和需求驗(yàn)證等操作過(guò)程。 2） 需求評(píng)審規(guī)程：對(duì)完成的系統(tǒng)需求進(jìn)行

6、組織內(nèi)外評(píng)審的過(guò)程； 3） 需求變更管理規(guī)程：需求基線(xiàn)產(chǎn)生后對(duì)需求進(jìn)行變更管理的過(guò)程； 4） 需求跟蹤管理規(guī)程：對(duì)需求進(jìn)行狀態(tài)跟蹤和過(guò)程跟蹤的管理過(guò)程； 5） 需求的測(cè)量和分析：對(duì)需求狀態(tài)和需求變化過(guò)程進(jìn)行測(cè)量和分析評(píng)估的管理過(guò)程；4）需求分析的特點(diǎn)需求分析工作的復(fù)雜性及面臨的潛在風(fēng)險(xiǎn)主要體現(xiàn)在以下方面： 1) 需求描述的準(zhǔn)確性問(wèn)題;2) 需求的完備程度問(wèn)題; 3) 需求開(kāi)發(fā)的時(shí)間問(wèn)題; 4) 需求的細(xì)化程度問(wèn)題; 5) 需求的變更問(wèn)題。5）需求開(kāi)發(fā)的十種常用方法1) 需求調(diào)查：采用需求調(diào)查表進(jìn)行需求收集和調(diào)查；2) 需求訪(fǎng)談：進(jìn)行面對(duì)面的需求訪(fǎng)談、記錄、整理并確認(rèn)；3) 資料收集和文檔考古：

7、收集業(yè)主方的有關(guān)資料進(jìn)行分析提煉；4) 需求研討：召開(kāi)需求研討會(huì)有目的的對(duì)需求進(jìn)行研討；5) 需求頭腦風(fēng)暴：發(fā)散式的對(duì)需求進(jìn)行遐想和探索；6) 需求原型：依據(jù)需求原型進(jìn)行需求溝通和探索，是電子政務(wù)行業(yè)常用的需求開(kāi)發(fā)方法；7) 實(shí)地學(xué)習(xí)：實(shí)地深入業(yè)主方業(yè)務(wù)現(xiàn)場(chǎng)進(jìn)行觀摩學(xué)習(xí)，以提煉需求；8) 實(shí)務(wù)跟蹤/實(shí)地工作：更加深入的跟蹤現(xiàn)場(chǎng)多個(gè)實(shí)物，甚至深入業(yè)主方現(xiàn)場(chǎng)進(jìn)行實(shí)地、實(shí)務(wù)長(zhǎng)時(shí)間、多案例的實(shí)地工作；9) 案例講述和故事板：通過(guò)對(duì)案例或故事的講解和分析獲取需求；10) 場(chǎng)景模擬/角色扮演：通過(guò)模擬一個(gè)場(chǎng)景或者由不同人員扮演不同的角色進(jìn)行需求模擬和角色分析，來(lái)獲取需求。6）需求建模方法 需求建模是軟件需

8、求工程過(guò)程的重要階段。不同的需求建模方法蘊(yùn)含了不同的建模理念，代表了看待軟件系統(tǒng)的不同視角。1、 結(jié)構(gòu)化需求分析方法自20 世紀(jì)70 年代中期以來(lái)，結(jié)構(gòu)化的需求建模方法一直是比較流行和普及的需求建模技術(shù)之一。它認(rèn)為系統(tǒng)的功能就是“數(shù)據(jù)”流經(jīng)系統(tǒng)時(shí)發(fā)生變遷的能力，同時(shí)需要外部事件觸發(fā)進(jìn)行完成變遷的過(guò)程。2、 面向?qū)ο蟮男枨蠓治龇椒嫦驅(qū)ο蟮男枨蠼７椒ㄊ钱?dāng)今工業(yè)界的主流方法，它認(rèn)為現(xiàn)實(shí)系統(tǒng)是由各種各樣的現(xiàn)實(shí)“對(duì)象”組成，對(duì)象可以被分類(lèi)、被描述、被組織、被操作、被創(chuàng)建，系統(tǒng)是要實(shí)現(xiàn)對(duì)現(xiàn)實(shí)世界實(shí)體(對(duì)象)的計(jì)算，需要在系統(tǒng)中建立這些實(shí)體的映像，這些實(shí)體的個(gè)體操作模型和交互模型就是系統(tǒng)的功能模型。面向

9、對(duì)象的需求建模方法的關(guān)鍵是從獲取的需求信息中識(shí)別出問(wèn)題域中的類(lèi)與對(duì)象，并分析它們之間的關(guān)系，最終建立起簡(jiǎn)潔、精確和易理解的需求模型。UML是隨著面向?qū)ο蠓椒òl(fā)展起來(lái)的統(tǒng)一建模語(yǔ)言，包括用來(lái)表示系統(tǒng)靜態(tài)結(jié)構(gòu)的用例圖、類(lèi)圖等，以及表示系統(tǒng)動(dòng)態(tài)結(jié)構(gòu)的狀態(tài)圖、活動(dòng)圖、序列圖、協(xié)作圖和配置圖等。3、面向問(wèn)題域的需求分析方法上述兩種傳統(tǒng)方法都只是針對(duì)軟件系統(tǒng)本身的建模方法，并沒(méi)有涉及軟件需求從哪里來(lái)、客戶(hù)存在什么問(wèn)題需要解決、為什么客戶(hù)會(huì)期望或者需要軟件來(lái)幫助它們解決這些問(wèn)題、他們需要軟件幫他們做什么等問(wèn)題。20 世紀(jì)90 年代之后，提出在進(jìn)行軟件系統(tǒng)建模之前，需要對(duì)軟件將處于的環(huán)境，即軟件將要解決的現(xiàn)實(shí)

10、世界的問(wèn)題進(jìn)行建模，需要對(duì)包含軟件及其環(huán)境的軟件加強(qiáng)型系統(tǒng)進(jìn)行建模，這樣才能識(shí)別出或者推導(dǎo)出人們對(duì)軟件的真正需求。面向問(wèn)題域(Problem Domain，PD) 的需求分析方法 (Problem Domain-Oriented Analysis，PDOA) 是由MJackson和P.Zave等人提出的一種需求分析方法。與傳統(tǒng)的結(jié)構(gòu)化需求分析方法和面向?qū)ο笮枨蠓治龇椒ㄏ啾蕊@著不同，其本質(zhì)在于從待求解問(wèn)題的角度，考慮待開(kāi)發(fā)的軟件系統(tǒng)將在與待求解問(wèn)題相關(guān)的域內(nèi)產(chǎn)生的效果。面向問(wèn)題域建模的核心是問(wèn)題框架。問(wèn)題框架方法認(rèn)為，軟件系統(tǒng)對(duì)現(xiàn)實(shí)世界的作用是軟件問(wèn)題的來(lái)源，對(duì)軟件系統(tǒng)將與現(xiàn)實(shí)世界發(fā)生的作用進(jìn)行

11、結(jié)構(gòu)化分析是需求分析的切入點(diǎn)。問(wèn)題框架方法強(qiáng)調(diào)需要對(duì)軟件系統(tǒng)將要作用的客觀現(xiàn)實(shí)世界進(jìn)行刻畫(huà)，并將需求的含義指稱(chēng)（映射）到對(duì)現(xiàn)實(shí)世界相關(guān)領(lǐng)域的描述上。其建模的基本概念是現(xiàn)實(shí)世界中的領(lǐng)域以及未來(lái)軟件系統(tǒng)與領(lǐng)域的交互。問(wèn)題框架方法定義了一些常見(jiàn)的軟件問(wèn)題類(lèi)型，稱(chēng)為問(wèn)題框架。問(wèn)題框架方法的基本思想就是在問(wèn)題分析中使用問(wèn)題框架，將復(fù)雜的現(xiàn)實(shí)世界軟件問(wèn)題結(jié)構(gòu)化為相互作用的可以匹配到問(wèn)題框架的子問(wèn)題的集合。基于問(wèn)題框架方法進(jìn)行需求建模，其第1 類(lèi)概念是現(xiàn)實(shí)世界中的領(lǐng)域和未來(lái)軟件系統(tǒng)與領(lǐng)域的交互。它認(rèn)為，系統(tǒng)的功能體現(xiàn)在未來(lái)軟件系統(tǒng)與現(xiàn)實(shí)世界領(lǐng)域的交互下產(chǎn)生的對(duì)現(xiàn)實(shí)世界領(lǐng)域的作用效果。在問(wèn)題框架方法中，用機(jī)器

12、領(lǐng)域顯式地表示了要?jiǎng)?chuàng)建的軟件系統(tǒng)。用問(wèn)題領(lǐng)域建模現(xiàn)實(shí)世界領(lǐng)域，嚴(yán)格區(qū)分了問(wèn)題領(lǐng)域和機(jī)器領(lǐng)域，由此確定了問(wèn)題的邊界，卻又不涉及任何關(guān)于機(jī)器領(lǐng)域的細(xì)節(jié)描述。由此避免過(guò)早進(jìn)入問(wèn)題的解決方案。它強(qiáng)調(diào)在關(guān)注解決方案之前關(guān)注問(wèn)題本身，盡可能地識(shí)別出關(guān)鍵的困難并盡早地加以解決。這是它與其他需求工程方法的根本區(qū)別。7）主要概念區(qū)分 1、項(xiàng)目范圍管理 項(xiàng)目范圍管理，包括為成功完成項(xiàng)目所需要的一系列過(guò)程，以確保項(xiàng)目包含且僅僅只包含項(xiàng)目所必須完成的工作。范圍管理首先要定義和控制在項(xiàng)目?jī)?nèi)包括什么、不包括什么。一般來(lái)說(shuō)，范圍分為產(chǎn)品范圍和項(xiàng)目范圍：1) 產(chǎn)品范圍是指表示產(chǎn)品或服務(wù)的特性和功能。2) 項(xiàng)目范圍是指為了完成

13、具有所規(guī)定特征和功能的產(chǎn)品必須完成的工作（需求定義）。項(xiàng)目范圍是否完成以項(xiàng)目管理計(jì)劃作為衡量標(biāo)準(zhǔn)，而產(chǎn)品范圍是否完成以產(chǎn)品需求作為衡量標(biāo)準(zhǔn)。兩種范圍管理需要很好地集成起來(lái)，以確保項(xiàng)目工作能產(chǎn)生所規(guī)定的產(chǎn)品并準(zhǔn)時(shí)交付。2、需求開(kāi)發(fā)、需求管理、項(xiàng)目范圍管理的區(qū)別和聯(lián)系主要如下：1) 首先通過(guò)需求開(kāi)發(fā)來(lái)獲取項(xiàng)目的需求, 在此基礎(chǔ)上確定項(xiàng)目的范圍，進(jìn)行項(xiàng)目范圍管理。2) 對(duì)于項(xiàng)目需求, 可以根據(jù)需求的緊急重要程度、項(xiàng)目本身和項(xiàng)目雙方的實(shí)際情況，分步或分期滿(mǎn)足。確定每期應(yīng)滿(mǎn)足的需求后，本期的范圍管理就有了基礎(chǔ)。3) 需求管理處理需求的變更，需求的變更同時(shí)會(huì)引起項(xiàng)目范圍的變更。二、CMMI需求開(kāi)發(fā)過(guò)程1）

14、基本概念CMMI提出了需求開(kāi)發(fā)-RD，要理解好RD PA (Process Area, 過(guò)程域) ，需要先理解清楚以下幾個(gè)關(guān)鍵的概念： 客戶(hù)需求(Customer Requirements)：客戶(hù)需求可以理解成客戶(hù)為什么要做本系統(tǒng)，要解決什么問(wèn)題，客戶(hù)對(duì)系統(tǒng)有怎樣的期望，希望能具備一些怎樣的特點(diǎn)，簡(jiǎn)單的說(shuō)，就是客戶(hù)的需求是什么（通常會(huì)包括對(duì)系統(tǒng)目標(biāo)、范圍、解決問(wèn)題、軟件特性、接口要求等有詳細(xì)的描述）。 產(chǎn)品需求(Product Requirements)：產(chǎn)品需求是能滿(mǎn)足客戶(hù)需求，并對(duì)軟件產(chǎn)品規(guī)格進(jìn)行了詳細(xì)描述的需求，軟件設(shè)計(jì)師可以根據(jù)產(chǎn)品需求進(jìn)行設(shè)計(jì)、編碼等工作。 產(chǎn)品組件需求(Produc

15、t Component Requirements)：產(chǎn)品組件需求是對(duì)產(chǎn)品需求的進(jìn)一步細(xì)化，產(chǎn)品可能會(huì)分割成幾個(gè)子系統(tǒng)、幾個(gè)部分，每個(gè)子系統(tǒng)每部分要具備怎樣的功能、要具備怎樣的性能、接口要求等，這些可以認(rèn)為是產(chǎn)品組件需求。圖 2-需求間的層次關(guān)系從另外一個(gè)角度，需求可以分為功能性需求和非功能性需求兩類(lèi)。功能性需求就是系統(tǒng)具備怎樣的功能，能做什么事情，而非功能性需求就是指系統(tǒng)要具備怎樣的性能、安全級(jí)別等方面的要求。軟件需求分為三大部分： 功能需求：指系統(tǒng)需要完成那些事情，即向用戶(hù)提供那些功能。 非功能需求：指產(chǎn)品所具備的品質(zhì)和屬性，比如可靠性、擴(kuò)展性、響應(yīng)時(shí)間、性能等 設(shè)計(jì)約束與限制：也稱(chēng)條件約束

16、、補(bǔ)充規(guī)則。比如用戶(hù)要安裝該產(chǎn)品他需要有什么樣的必備條件。（系統(tǒng)對(duì)操作系統(tǒng)的要求、硬件環(huán)境的要求等）客戶(hù)需求、產(chǎn)品需求和產(chǎn)品組件需求，都會(huì)包含功能需求和非功能需求。2）需求調(diào)查方法 需求調(diào)查與問(wèn)題定義，在做需求調(diào)查時(shí)需要做到2W1H即 What、Where、How What-應(yīng)該收集什么信息 Where-從什么地方收集 How-用什么機(jī)制或技術(shù)來(lái)收集客戶(hù)需求一般都是比較高層次的，而且描述也會(huì)比較簡(jiǎn)單，不能作為日后驗(yàn)收的標(biāo)準(zhǔn)，我們需要對(duì)軟件的規(guī)格進(jìn)行說(shuō)明。當(dāng)我們明確客戶(hù)需求后，就應(yīng)該把客戶(hù)需求轉(zhuǎn)變成產(chǎn)品需求和產(chǎn)品組件需求。而產(chǎn)品和產(chǎn)品組件需求，是比較細(xì)致的需求，會(huì)詳細(xì)描述軟件與用戶(hù)是怎樣交互的，

17、用戶(hù)需要輸入什么，系統(tǒng)會(huì)輸出什么等都會(huì)比較詳細(xì)描述出來(lái)。客戶(hù)需求一般是難以驗(yàn)證是否已實(shí)現(xiàn)的，而產(chǎn)品需求和產(chǎn)品組件需求是對(duì)軟件規(guī)格的描述，是可以用來(lái)做為驗(yàn)收的標(biāo)準(zhǔn)的。一般來(lái)說(shuō)，我們寫(xiě)的軟件規(guī)格說(shuō)明書(shū)（SRS, Software Requirement Specification）都會(huì)包含產(chǎn)品需求和產(chǎn)品組件需求的。我們導(dǎo)出產(chǎn)品需求和產(chǎn)品組件需求的時(shí)候，要注意產(chǎn)品需求和產(chǎn)品組件需求，必須和客戶(hù)需求對(duì)應(yīng)起來(lái)，通常是多對(duì)多的關(guān)系。為什么要對(duì)應(yīng)起來(lái)？我們要保證，軟件的每一個(gè)界面，每一個(gè)功能都是有用的，都是“源自”客戶(hù)需求的，這樣才能保證我們做的事情都是正確的事情，防止被不相干的事情干擾。我們經(jīng)常抱怨客戶(hù)的

18、需求在變，其實(shí)80%的原因是沒(méi)有把握住客戶(hù)需求，其實(shí)客戶(hù)經(jīng)常變的是產(chǎn)品需求或者是產(chǎn)品組件需求，客戶(hù)需求是很少變的，就是因?yàn)槲覀儧](méi)有把握住客戶(hù)到底想要什么、需要什么，導(dǎo)致我們認(rèn)為客戶(hù)太難“服侍”了。只有把握住客戶(hù)真正的需求，我們才能抓住根本，萬(wàn)變不離其中。3）CMMI需求分析過(guò)程CMMI第二級(jí)（初始級(jí)，管理級(jí)，定義級(jí)，量化管理級(jí)和優(yōu)化級(jí)共5級(jí)），即管理級(jí)，包含了需求分析等過(guò)程。需求開(kāi)發(fā)過(guò)程：RD有三個(gè)SG（Special Goal），SG1開(kāi)發(fā)客戶(hù)需求，SG2開(kāi)發(fā)產(chǎn)品需求，SG3分析和確認(rèn)需求。前兩個(gè)SG講述的是需求開(kāi)發(fā)由頂而下、由粗到細(xì)的過(guò)程，SG3講述的是需求分析和確認(rèn)的過(guò)程。SG(特定目標(biāo)

19、)SP(特定實(shí)踐)干系人的需要、期望、約束和接口要求被收集并轉(zhuǎn)化為客戶(hù)需求（Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements）SP1.1 導(dǎo)出干系人對(duì)整個(gè)產(chǎn)品生命周期各階段的需要、期望、約束和接口要求等（Elicit stakeholder needs, expectations, constrains, and interfaces for all phases of the product life cycl

20、e）：要包含了幾個(gè)要點(diǎn)：1) 干系人：干系人除了指甲方的領(lǐng)導(dǎo)、系統(tǒng)的最終用戶(hù)，還包括使用本系統(tǒng)的第三方以及與本系統(tǒng)有交互的第三方系統(tǒng)的擁有者、使用者等。2) 產(chǎn)品生命周期各階段：干系人對(duì)系統(tǒng)的期望不一定只限于軟件功能的，可能還包括數(shù)據(jù)的整理、資料錄入、安裝培訓(xùn)、維護(hù)要求等，干系人可能對(duì)軟件生產(chǎn)的過(guò)程階段都會(huì)提出他的要求，獲取需求的時(shí)候，要注意干系人在軟件生命周期不同階段有什么要求。3) 需要、期望、約束、接口要求：甲方一般會(huì)對(duì)系統(tǒng)的目標(biāo)、范圍、解決什么問(wèn)題、希望系統(tǒng)具備怎樣的一些特性，滿(mǎn)足一些什么接口要求和約束條件等，都會(huì)有大致的想法。需求調(diào)研工作，首先要注意搞清楚這些內(nèi)容。4) 導(dǎo)出：客戶(hù)的

21、原始想法可能是不明確的，或者是客戶(hù)一時(shí)難表達(dá)完整的，我們需要用一定的方法，讓客戶(hù)能完整無(wú)遺漏準(zhǔn)確地表達(dá)出他的想法。通常我們可以通過(guò)原型、圖示、類(lèi)比、問(wèn)卷等辦法來(lái)導(dǎo)出客戶(hù)的需求。SP1.2轉(zhuǎn)化干系人的需要、期望、約束和接口要求為客戶(hù)需求 (Transform stakeholder needs, expectations, constraints and interfaces into customer requirements) 。上一個(gè)SP1.1講述的是通過(guò)一些方法記錄客戶(hù)原始的需求信息，而SP1.2講述的就是把客戶(hù)原始的需求信息整理成正式的客戶(hù)需求，通常會(huì)包括對(duì)系統(tǒng)目標(biāo)、范圍、解決問(wèn)題、軟

22、件特性、接口要求等有詳細(xì)的描述。客戶(hù)需求是精確和詳細(xì)的，以用來(lái)開(kāi)發(fā)產(chǎn)品需求和產(chǎn)品組件需求（Customer requirements are refined and elaborated to develop product and product-components requirements）。SP 2.1:建立和維護(hù)產(chǎn)品和產(chǎn)品組件需求，這些產(chǎn)品和產(chǎn)品組件需求是基于客戶(hù)需求的（Establish and maintain product and product-component requirements, which are based on the customer requireme

23、nts）。產(chǎn)品和產(chǎn)品組件需求，是比較細(xì)致的需求，會(huì)詳細(xì)描述軟件與用戶(hù)是怎樣交互的，用戶(hù)需要輸入什么，系統(tǒng)會(huì)輸出什么等都會(huì)比較詳細(xì)描述出來(lái)。而客戶(hù)需求一般只描述能實(shí)現(xiàn)什么功能、解決什么問(wèn)題等，比較高層次。客戶(hù)需求一般是難以驗(yàn)證是否已實(shí)現(xiàn)的，而產(chǎn)品需求和產(chǎn)品組件需求是對(duì)軟件規(guī)格的描述，是可以用來(lái)做為驗(yàn)收的標(biāo)準(zhǔn)的。SP 2.2: 分配需求給每一個(gè)產(chǎn)品組件（Allocate the requirements for each product component）。這個(gè)SP將需求開(kāi)發(fā)與技術(shù)解決方案聯(lián)系起來(lái)，所有的需求應(yīng)該與設(shè)計(jì)的產(chǎn)品組件對(duì)應(yīng)起來(lái)，保證需求驅(qū)動(dòng)后續(xù)的設(shè)計(jì)工作，同時(shí)也保證設(shè)計(jì)都是為了需求服務(wù)

24、的。SP2.2是對(duì)SP2.1的進(jìn)一步細(xì)化。SP 2.3:定義接口需求（Identify interface requirements）。接口需求包括系統(tǒng)與第三方的系統(tǒng)的接口要求，也包括系統(tǒng)本身各組件、各子系統(tǒng)、各部分之間的接口要求。通常這些接口需求在客戶(hù)需求級(jí)別的時(shí)候，并不是很明細(xì)，需要對(duì)客戶(hù)需求進(jìn)一步細(xì)分成產(chǎn)品需求、產(chǎn)品組件需求，然后發(fā)掘出接口需求。SP2.3也是對(duì)SP2.1的進(jìn)一步深化。需求被分析和確認(rèn)，并定義出具體的功能性需求（The requirements are analyzed and validated, and a definition of required functio

25、nality is developed）。SP 3.1:建立和維護(hù)操作場(chǎng)景及相關(guān)情景（Establish and maintain operational concepts and associated scenarios）。SP 3.2:建立和維護(hù)功能定義（Establish and maintain a definition of required functionality）。SP3.1和SP3.2是對(duì)需求描述的要求，要求描述出具體需求的操作場(chǎng)景、上下文，具體的操作步驟，對(duì)功能的詳細(xì)描述等。通常我們可以通過(guò)UML的Use Case圖或者是序列圖等來(lái)表達(dá)這些內(nèi)容。SP 3.3: 分析需求以

26、確認(rèn)需求是必須和充分的（Analyze requirements to ensure that they are necessary and sufficient.）。SP 3.4:分析需求平衡以平衡干系人的需要和約束（Analyze requirements to balance stakeholder needs and constrains）。SP3.3和SP3.4是對(duì)需求的準(zhǔn)確性、全面性、可實(shí)現(xiàn)性方面的要求，除了要取得全面準(zhǔn)確地需求，還需要平衡約束條件，保證需求在約束條件下是可實(shí)現(xiàn)的。SP 3.5:用各種合適的方法確認(rèn)需求，確保最終產(chǎn)品能在用戶(hù)的環(huán)境中按照設(shè)想運(yùn)行（Validate r

27、equirements to ensure the resulting product will perform as intended in the users environment using multiple techniques as appropriate）。這是需求開(kāi)發(fā)的最后一步了，需求導(dǎo)出過(guò)程中盡管用了很多辦法，但需求確認(rèn)的時(shí)候，仍然需要采取辦法確保獲取的需求是符合最終的使用場(chǎng)景要求。SP3.3、SP3.4和SP3.5，通常是通過(guò)需求評(píng)審來(lái)滿(mǎn)足的。三、需求管理工具介紹1）Rational RequisitePro IBM Rational RequisitePro 是一個(gè)強(qiáng)大、

28、易用、集成的需求管理產(chǎn)品。而通過(guò)與Rational系列軟件產(chǎn)品的廣泛集成，大大擴(kuò)展了RequisitePro及其它產(chǎn)品的功能，給軟件工程生命周期內(nèi)的各個(gè)階段都提供了強(qiáng)大、方便的信息查詢(xún)、跟蹤、管理功能。從而能夠促進(jìn)更好的團(tuán)隊(duì)溝通、幫助管理變更和評(píng)估變更的影響，幫助驗(yàn)證所有的規(guī)劃需求被交付物所滿(mǎn)足、降低項(xiàng)目風(fēng)險(xiǎn)。Rational RequisitePro helps project teams to manage their requirements, to write good use cases, to improve traceability, to strengthen collabor

29、ation, to reduce project rework, and to increase quality. Avoid rework and duplication using advanced, real-time integration with Microsoft Word Manage complexity with detailed traceability views that display parent/child relationships Mitigate project risk with display of requirements that may be a

30、ffected by upstream or downstream changes of requirements Achieve collaboration for geographically distributed teams through fully functional, scalable Web interface and discussion threads Capture and analyze requirements information with detailed attribute customization and filtering Improve produc

31、tivity by tracking changes using project version comparisons with XML-based project baselines Align business goals and objectives with project deliverables though integration with multiple tools in the IBM Rational software development and delivery platform Operating systems supported: Windows famil

32、y詳細(xì)信息參考2）IBM Rational DOORS IBM Rational DOORS前身是大名鼎鼎的Telelogic DOORS，被IBM收購(gòu)后更名為IBM Rational DOORS。DOORS 是最老牌的企業(yè)需求管理套件，通過(guò)使用DOORS/ERS，可以幫助企業(yè)更有效地進(jìn)行溝通并加強(qiáng)協(xié)作與驗(yàn)證，從而降低失敗的風(fēng)險(xiǎn)。通過(guò)對(duì)整個(gè)組織實(shí)施多種需求管理的方法，可以使項(xiàng)目的管理更加透明。它可以使企業(yè)跨越地域與組織的邊界來(lái)按國(guó)際化的方式運(yùn)行。 IBM Rational DOORS software is a leading requirements management applicati

33、on that can help you reduce costs, increase efficiency and improve quality by enabling you to optimize requirements communication, collaboration and verification throughout your organization and across your supply chain. Provides a comprehensive requirements management environment Actively engaging

34、all stakeholders in a collaborative requirements process by providing web browser access to the requirements database and integration to requirements definition capabilities Manages changes to requirements with either a simple pre-defined change proposal system or a more thorough, customizable chang

35、e control workflow through integration to Rationals change management solutions. Supports the Requirements Interchange Format, which enables suppliers and development partners to be directly involved in the development process Links requirements to design items, test plans, test cases and other requ

36、irements for easy and powerful traceability Scales to address your changing requirements management needs Enables informal requirements discussions with DOORS Discussions Includes the Test Tracking Toolkit for manual test environments, so testers can link requirements to test cases Supports the Open

37、 Services for Lifecycle Collaboration (OSLC) specifications for requirements management, change management and quality management which provides a generic and open way to integrate systems and software lifecycle tools. Integrations include Rational change management solutions, Rational Rhapsody, Rational Quality Manager, Rational Focal Point, Rational System Architect, Rational Software Architect (through partner), Rational Requirements Composer and many third-party tools, to provide a comprehensive traceabil