基于構(gòu)件的開發(fā)方法使得軟件開發(fā)不再一切從頭開始，開發(fā)的過程就是構(gòu)件組裝的過程，維護(hù)的過程就是構(gòu)件升級(jí)、替換和擴(kuò)充的過程，其優(yōu)點(diǎn)是構(gòu)件組裝模型導(dǎo)致了軟件的復(fù)用，提高了軟件開發(fā)的效率；構(gòu)件可由一方定義其規(guī)格說明，被另一方實(shí)現(xiàn)，然后供給第三方使用；構(gòu)件組裝模型允許多個(gè)項(xiàng)目同時(shí)開發(fā)，降低了費(fèi)用，提高了可維護(hù)性，可實(shí)現(xiàn)分步提交軟件產(chǎn)品。
缺點(diǎn)是由于采用自定義的組裝結(jié)構(gòu)標(biāo)準(zhǔn)，缺乏通用的組裝結(jié)構(gòu)標(biāo)準(zhǔn)，引入具有較大的風(fēng)險(xiǎn)；可重用性和軟件高效性不易協(xié)調(diào)，需要精干的、有經(jīng)驗(yàn)的分析人員和開發(fā)人員，一般的開發(fā)人員插不上手，客戶的滿意度低；過分依賴于構(gòu)件，構(gòu)件庫(kù)的質(zhì)量影響著產(chǎn)品質(zhì)量。

3.8 敏捷模型

開發(fā)宣言：個(gè)體和交互勝過過程和工具、可以工作的軟件勝過面面俱到的文檔、客戶合作勝過合同談判、響應(yīng)變化勝過遵循計(jì)劃。

敏捷開發(fā)方法

敏捷方法區(qū)別與其他方法的兩個(gè)特點(diǎn)：
（1）是”適應(yīng)性“而非“預(yù)設(shè)性”。
（2）是“面向人的”而非“面向過程的”。
敏捷開發(fā)核心思想：
（1）敏捷開發(fā)是適應(yīng)型，而非可預(yù)測(cè)型。擁抱變化，適應(yīng)變化。
（2）敏捷開發(fā)是以人為本，而非以過程為本。發(fā)揮人的特性。
（3）迭代增量式的開發(fā)過程。以原型開發(fā)思想為基礎(chǔ)，采用法代替增量式開發(fā)，發(fā)行版本小型化。

XP極限編程

XP是一種輕量（敏捷）、高效、低風(fēng)險(xiǎn)、柔性、可預(yù)測(cè)、科學(xué)而且充滿樂趣的軟件開發(fā)方式。與其他方法論相比，其最大的不同在于：

（1）以代碼驅(qū)動(dòng)的規(guī)則，其重要的文檔是源代碼。
（2）在更短的周期內(nèi)，更早地提供具體、持續(xù)的反饋信息。
（3）迭代地進(jìn)行計(jì)劃編制，首先在最開始迅速生成一個(gè)總體計(jì)劃，然后在整個(gè)項(xiàng)目開發(fā)過程中不斷地發(fā)展它。
（4）依賴于自動(dòng)測(cè)試程序來監(jiān)控開發(fā)進(jìn)度，并及早地捕獲缺陷。
（5）依賴于口頭交流、測(cè)試和源程序進(jìn)行溝通。
（6）倡導(dǎo)持續(xù)的演化式的設(shè)計(jì)。
（7）依賴于開發(fā)團(tuán)隊(duì)內(nèi)部的緊密協(xié)作。
（8）盡可能達(dá)到程序員短期利益和項(xiàng)目長(zhǎng)期利益的平衡。

四大價(jià)值觀：

• 溝通，加強(qiáng)面對(duì)面溝通
• 簡(jiǎn)單，不過度設(shè)計(jì)
• 反饋，及時(shí)反饋
• 勇氣，接受變更的勇氣

XP是一種近螺旋式的開發(fā)方法，它將復(fù)雜的開發(fā)過程分解為一個(gè)個(gè)相對(duì)比較簡(jiǎn)單的小周期:通過積極的交流、反饋以及其他一系列的方法，開發(fā)人員和客戶可以非常清楚開發(fā)進(jìn)度、變化待解決的問題和潛在的困難等，并根據(jù)實(shí)際情況及時(shí)地調(diào)整開發(fā)過程。

XP提倡測(cè)試先行，為了將以后出現(xiàn)bug的幾率降到最低。

XP一些對(duì)費(fèi)用控制嚴(yán)格的公司中的使用，非常有效。

水晶方法

水晶系列方法與XP方法一樣，都有以人為中心的理念，但在實(shí)踐上有所不同。其目的是發(fā)展一種提倡“機(jī)動(dòng)性的”方法，包含具有共性的核心元素，每個(gè)都含有獨(dú)特的角色、過程模式、工作產(chǎn)品和實(shí)踐。

水晶方法：探索了用最少紀(jì)律約束而仍能成功的方法，從而在產(chǎn)出效率與易于運(yùn)作上達(dá)到一種平衡。

開放式源碼

開放式源碼：程序開發(fā)人員在地域上分布很廣【其他方法強(qiáng)調(diào)集中辦公】。

并列爭(zhēng)求法

并列爭(zhēng)球法（SCRUM）是一種迭代的增量化過程，把每段時(shí)間（如30天）一次的迭代稱為一個(gè)“沖刺”（Sprint），并按需求的優(yōu)先級(jí)別來實(shí)現(xiàn)產(chǎn)品，多個(gè)自組織和自治的小組并行地遞增實(shí)現(xiàn)產(chǎn)品。

并列爭(zhēng)求法（SCRUM）：明確定義了的可重復(fù)的方法過程，側(cè)重于項(xiàng)目管理。。

特征驅(qū)動(dòng)開發(fā)方法（FDD）

特征驅(qū)動(dòng)開發(fā)方法（FDD）是一個(gè)迭代的開發(fā)模型。認(rèn)為有效的軟件開發(fā)需要3個(gè)要素：人、過程和技術(shù)。有5個(gè)核心過程：開發(fā)整體對(duì)象模型、構(gòu)造特征列表、計(jì)劃特征開發(fā)、特征設(shè)計(jì)和特征構(gòu)建。定義了6種關(guān)鍵的項(xiàng)目角色：項(xiàng)目經(jīng)理、首席架構(gòu)設(shè)計(jì)師、開發(fā)經(jīng)理、主程序員、程序員和領(lǐng)域?qū)＜摇?/p>

功用驅(qū)動(dòng)開發(fā)方法（FDD）：編程開發(fā)人員分成兩類：首席程序員和“類”程序員。

ASD方法

ASD方法：其核心是三個(gè)非線性的、重疊的開發(fā)階段：猜測(cè)、合作與學(xué)習(xí)。

動(dòng)態(tài)系統(tǒng)開發(fā)方法

動(dòng)態(tài)系統(tǒng)開發(fā)方法（DSDM）：倡導(dǎo)以__業(yè)務(wù)為核心。

3.9 RAD模型（快速應(yīng)用開發(fā)模型）

快速應(yīng)用開發(fā)（Rapid Application Development，RAD）模型是一個(gè)增量型的軟件開發(fā)過程模型，強(qiáng)調(diào)極短的開發(fā)周期。RAD模型是瀑布模型的一個(gè)“高速”變種，通過大量使用可復(fù)用構(gòu)件，采用基于構(gòu)件的建造方法贏得快速開發(fā)。如果需求理解得好且約束了項(xiàng)目的范圍，利用這種模型可以很快地創(chuàng)建出功能完善的“信息系統(tǒng)“。其流程從業(yè)務(wù)建模開始，隨后是數(shù)據(jù)建模、過程建模、應(yīng)用生成、測(cè)試及反復(fù)。瀑布模型和CBSD（Component-Based Software Development基于構(gòu)建的軟件開發(fā)模型）的綜合開發(fā)模型，如圖：

RAD模型各個(gè)活動(dòng)期所要完成的任務(wù)如下：

• 業(yè)務(wù)建模：以什么信息驅(qū)動(dòng)業(yè)務(wù)過程運(yùn)作？要生成什么信息？誰生成它？信息流的去向是哪里？由誰處理？可以輔之以數(shù)據(jù)流圖。
• 數(shù)據(jù)建模：為支持業(yè)務(wù)過程的數(shù)據(jù)流，找數(shù)據(jù)對(duì)象集合，定義數(shù)據(jù)對(duì)象屬性，與其他數(shù)據(jù)對(duì)象的關(guān)系構(gòu)成數(shù)據(jù)模型，可輔之以E-R圖。
• 過程建模：使數(shù)據(jù)對(duì)象在信息流中完成各業(yè)務(wù)功能。創(chuàng)建過程以描述數(shù)據(jù)對(duì)象的增加、修改、刪除、查找，即細(xì)化數(shù)據(jù)流圖中的處理框。
• 應(yīng)用程序生成：利用第四代語言（4GL）寫出處理程序，重用已有構(gòu)件或創(chuàng)建新的可重用構(gòu)件，利用環(huán)境提供的工具自動(dòng)生成并構(gòu)造出整個(gè)應(yīng)用系統(tǒng)。
• 測(cè)試與交付，由于大量重用，一般只做總體測(cè)試，但新創(chuàng)建的構(gòu)件還是要測(cè)試的。

與瀑布模型相比，RAD模型不采用傳統(tǒng)的第三代程序設(shè)計(jì)語言來創(chuàng)建軟件，而是采用基于構(gòu)件的開發(fā)方法，復(fù)用已有的程序結(jié)構(gòu)（如果可能的話）或使用可復(fù)用構(gòu)件，或創(chuàng)建可復(fù)用的構(gòu)件（如果需要的話）。在所有情況下，均使用自動(dòng)化工具輔助軟件創(chuàng)造。很顯然，加在一個(gè)RAD模型項(xiàng)目上的時(shí)間約束需要“一個(gè)可伸縮的范圍”。如果一個(gè)業(yè)務(wù)能夠被模塊化使得其中每一個(gè)主要功能均可以在不到三個(gè)月的時(shí)間內(nèi)完成，那么它就是RAD的一個(gè)候選者。每一個(gè)主要功能可由一個(gè)單獨(dú)的RAD組來實(shí)現(xiàn)，最后再集成起來形成一個(gè)整體。

RAD模型通過大量使用可復(fù)用構(gòu)件加快了開發(fā)速度，對(duì)信息系統(tǒng)的開發(fā)特別有效。但是像所有其他軟件過程模型一樣，RAD方法也有其缺陷：

• 并非所有應(yīng)用都適合RAD。RAD模型對(duì)模塊化要求比較高，如果有哪一項(xiàng)功能不能被模塊化，那么建造RAD所需要的構(gòu)件就會(huì)有問題；如果高性能是一個(gè)指標(biāo)，且該指標(biāo)必須通過調(diào)整接口使其適應(yīng)系統(tǒng)構(gòu)件才能贏得，RAD方法也有可能不能奏效。
• 開發(fā)者和客戶必須在很短的時(shí)間完成一系列的需求分析，任何一方配合不當(dāng)都會(huì)導(dǎo)致RAD項(xiàng)目失敗。
• RAD只能用于信息系統(tǒng)開發(fā)，不適合技術(shù)風(fēng)險(xiǎn)很高的情況。當(dāng)一個(gè)新應(yīng)用要采用很多新技術(shù)或當(dāng)新軟件要求與已有的計(jì)算機(jī)程序有較高的互操作性時(shí)，這種情況就會(huì)發(fā)生。

3.10 統(tǒng)一過程模型（RUP/UP）

RUP的特點(diǎn)

（1）用例驅(qū)動(dòng)：需求分析、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試等活動(dòng)都是用例驅(qū)動(dòng)的。
（2）以架構(gòu)為中心：包括系統(tǒng)的總體組織和全局控制、通信協(xié)議等。是一個(gè)多維的結(jié)構(gòu)，會(huì)采用多個(gè)視圖（4 + 1 視圖） 來描述。
（3）迭代與增量：把整個(gè)項(xiàng)目開發(fā)分為多個(gè)迭代過程。在每次選代中，只考慮系統(tǒng)的一部分需求，進(jìn)行分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試和部署等過程;每次迭代是在己完成部分的基礎(chǔ)上進(jìn)行的，每次增加一些新的功能實(shí)現(xiàn)，以此進(jìn)行下去，直至最后項(xiàng)目的完成。

RUP中有4個(gè)階段

統(tǒng)一軟件開發(fā)過程定義了四種開發(fā)階段，它們按照過程順序分別是起始階段，細(xì)化階段，構(gòu)建階段和交付階段，其中在構(gòu)建階段主要產(chǎn)生的文檔有設(shè)計(jì)模型。

• 初始階段：項(xiàng)目藍(lán)圖文檔（核心需求，關(guān)鍵特征，主要約束），用例模型，項(xiàng)目計(jì)劃

• 細(xì)化階段：完成架構(gòu)設(shè)計(jì)，淘汰高風(fēng)險(xiǎn)元素

• 構(gòu)造階段：UML模型，測(cè)試用例

• 交付階段：可運(yùn)行的軟件產(chǎn)品，用戶手冊(cè)，用戶支持計(jì)劃。

RUP中有9個(gè)核心工作流

RUP的工作流程分為兩部分：核心工作流程與核心支持工作流程。核心工作流程（在項(xiàng)目中的流程）包括業(yè)務(wù)需求建模、分析設(shè)計(jì)、實(shí)施、測(cè)試、部署；核心支持工作流程（在組織中的流程）包括環(huán)境、項(xiàng)目管理、配置與變更管理。

RUP軟件開發(fā)生命周期是一個(gè)二維的軟件開發(fā)模型，RUP中有9個(gè)核心工作流，如下：

• 業(yè)務(wù)建模：理解待開發(fā)系統(tǒng)所在的機(jī)構(gòu)及其商業(yè)運(yùn)作，確保所有參與人員對(duì)待開發(fā)系統(tǒng)所在的機(jī)構(gòu)有共同的認(rèn)識(shí)，評(píng)估待開發(fā)系統(tǒng)對(duì)所在機(jī)構(gòu)的影響。
• 需求：定義系統(tǒng)功能及用戶界面，使客戶知道系統(tǒng)的功能，使開發(fā)人員理解系統(tǒng)的需求，為項(xiàng)目預(yù)算及計(jì)劃提供基礎(chǔ)。
• 分析與設(shè)計(jì)：把需求分析的結(jié)果轉(zhuǎn)化為分析與設(shè)計(jì)模型。
• 實(shí)現(xiàn)：把設(shè)計(jì)模型轉(zhuǎn)換為實(shí)現(xiàn)結(jié)果，對(duì)開發(fā)的代碼做單元測(cè)試，將不同實(shí)現(xiàn)人員開發(fā)的模塊集成為可執(zhí)行系統(tǒng)。
• 測(cè)試：檢查各子系統(tǒng)之間的交互、集成，驗(yàn)證所有需求是否均被正確實(shí)現(xiàn)，對(duì)發(fā)現(xiàn)的軟件質(zhì)量上的缺陷進(jìn)行歸檔，對(duì)軟件質(zhì)量提出改進(jìn)建議。
• 部署：打包、分發(fā)、安裝軟件，升級(jí)舊系統(tǒng)；培訓(xùn)用戶及銷售人員，并提供技術(shù)支持。
• 配置與變更管理：跟蹤并維護(hù)系統(tǒng)開發(fā)過程中產(chǎn)生的所有制品的完整性和一致性。
• 項(xiàng)目管理：為軟件開發(fā)項(xiàng)目提供計(jì)劃、人員分配、執(zhí)行、監(jiān)控等方面的指導(dǎo)，為風(fēng)險(xiǎn)管理提供框架。
• 環(huán)境：為軟件開發(fā)機(jī)構(gòu)提供軟件開發(fā)環(huán)境，即提供過程管理和工具的支持。

四、逆向工程

逆向工程的特點(diǎn)是從已有的程序中抽取數(shù)據(jù)結(jié)構(gòu)，體系結(jié)構(gòu)和程序設(shè)計(jì)信息。

它的流程為：現(xiàn)有系統(tǒng) → 逆向工程 → 考慮新需求 → 正向工程 → 新系統(tǒng)。

軟件的逆向工程是一個(gè)恢復(fù)設(shè)計(jì)的過程，從現(xiàn)有的程序中抽取數(shù)據(jù)，體系結(jié)構(gòu)和過程設(shè)計(jì)信息。逆向工程的完備性可以用在某一個(gè)抽象層次上提供信息的詳細(xì)程度來描述，在大多數(shù)情況下，抽象層次越高，完備性就越低。

領(lǐng)域級(jí)抽象級(jí)別最高，完備性最低，實(shí)現(xiàn)級(jí)抽象級(jí)別最低，完備性最高。

與逆向工程相關(guān)的概念有重構(gòu)、設(shè)計(jì)恢復(fù)、再工程和正向工程：

• 重構(gòu)（restructuring），重構(gòu)是指在同一抽象級(jí)別上轉(zhuǎn)換系統(tǒng)描述形式。
• 設(shè)計(jì)恢復(fù)（design recovery），設(shè)計(jì)恢復(fù)是指借助工具從已有程序中抽象出有關(guān)數(shù)據(jù)設(shè)計(jì)、總體結(jié)構(gòu)設(shè)計(jì)和過程設(shè)計(jì)等方面的信息。
• 逆向工程（reverse engineering），逆向工程是分析程序，力圖在比源代碼更高抽象層次上建立程序的表示過程，逆向工程是設(shè)計(jì)的恢復(fù)過程。
• 正向工程（forward engineering），正向工程是指不僅從現(xiàn)有系統(tǒng)中恢復(fù)設(shè)計(jì)信息，而且使用該信息去改變或重構(gòu)現(xiàn)有系統(tǒng)，以改善其整體質(zhì)量。
• 再工程（re-engineering），再工程是對(duì)現(xiàn)有系統(tǒng)的重新開發(fā)過程，包括逆向工程、新需求的考慮過程和正向工程三個(gè)步驟。

逆向工程恢復(fù)信息的方法:

五、需求工程

2.1 軟件需求的層次

2.2 需求工程

軟件需求是指用戶對(duì)系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望。

需求工程（Requirement Engineering，RE） 是指應(yīng)用已證實(shí)有效的原理、方法，通過合適的工具和記號(hào)，系統(tǒng)地描述待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束。

需求工程由需求獲取、需求分析、形成需求規(guī)格（或稱為需求文檔化）、需求確認(rèn)與驗(yàn)證、需求管理5個(gè)階段，如圖：

軟件需求規(guī)格說明書（Software Requirement Specification，SRS）
SRS具體包括功能需求、非功能需求和約束。約束包括設(shè)計(jì)約束和過程約束。批準(zhǔn)的SRS是需求開發(fā)和需求管理之間的橋梁。

需求管理
需求管理是一個(gè)對(duì)系統(tǒng)需求變更、了解和控制的過程，包括變更控制、版本控制、需求跟蹤等活動(dòng)。

2.5 需求開發(fā)（主線、目標(biāo)）

2.5.1 需求分類

• 需求分類

（1）業(yè)務(wù)需求：業(yè)務(wù)需求是指反映企業(yè)或客戶對(duì)系統(tǒng)高層次的目標(biāo)要求，通常來自項(xiàng)目投資人、購(gòu)買產(chǎn)品的客戶、客戶單位的管理人員、市場(chǎng)營(yíng)銷部門或產(chǎn)品策劃部門等。通過業(yè)務(wù)需求可以確定項(xiàng)目視圖和范圍。

（2）用戶需求：用戶需求描述的是用戶的具體目標(biāo)，或用戶要求系統(tǒng)必須能完成的任務(wù)。也就是說，用戶需求描述了用戶能使用系統(tǒng)來做些什么。通常采取用戶訪談和問卷調(diào)查等方式，對(duì)用戶使用的場(chǎng)景（scenarios）進(jìn)行整理，從而建立用戶需求

（3）系統(tǒng)需求：系統(tǒng)需求是從系統(tǒng)的角度來說明軟件的需求，包括功能需求、非功能需求和設(shè)計(jì)約束等。

• 質(zhì)量功能部署QFD

它是一種將用戶要求轉(zhuǎn)化成軟件需求的技術(shù)，其目的是最大限度地提升軟件工程過程中用戶的滿意度。為了達(dá)到這個(gè)目標(biāo)，QFD將軟件需求分為三類，分別是常規(guī)需求、期望需求和意外需求。

（1）基本需求：也叫常規(guī)需求，用戶認(rèn)為系統(tǒng)應(yīng)該做到的功能或性能，實(shí)現(xiàn)越多用戶會(huì)越滿意。

（2）期望需求：用戶想當(dāng)然認(rèn)為系統(tǒng)應(yīng)具備的功能或性能，但并不能正確描述自己想要得到的這些功能或性能需求。如果期望需求沒有得到實(shí)現(xiàn)，會(huì)讓用戶感到不滿意。

（3）意外需求：意外需求也稱為興奮需求，是用戶要求范圍外的功能或性能（但通常是軟件開發(fā)人員很樂意賦予系統(tǒng)的技術(shù)特性），實(shí)現(xiàn)這些需求用戶會(huì)更高興，但不實(shí)現(xiàn)也不影響其購(gòu)買的決策。

2.5.2 需求獲取

• 用戶訪談
  用戶訪談是最基本的一種需求獲取手段，其形式包括結(jié)構(gòu)化和非結(jié)構(gòu)化兩種。結(jié)構(gòu)化是指事先準(zhǔn)備好一系列問題，有針對(duì)地進(jìn)行；而非結(jié)構(gòu)化則是只列出一個(gè)粗略的想法，根據(jù)訪談的具體情況發(fā)揮。最有效的訪談是結(jié)合這兩種方法進(jìn)行，畢竟不可能把什么都一一計(jì)劃清楚，應(yīng)該保持良好的靈活性。
  用戶訪談具有良好的靈活性，有較寬廣的應(yīng)用范圍。但是，也存在著許多困難，例如，用戶經(jīng)常較忙，難以安排時(shí)間；面談時(shí)信息量大，記錄較為困難；溝通需要很多技巧，同時(shí)需要系統(tǒng)分析師具有足夠的領(lǐng)域知識(shí)等。另外，在訪談時(shí)，還可能會(huì)遇到一些對(duì)于企業(yè)來說比較機(jī)密和敏感的話題。因此，這看似簡(jiǎn)單的技術(shù)，也需要系統(tǒng)分析師具有豐富的經(jīng)驗(yàn)和較強(qiáng)的溝通能力。

• 問卷調(diào)查
  問卷調(diào)查與用戶訪談相比，問卷調(diào)查可以在短時(shí)間內(nèi)，以低廉的代價(jià)從大量的回答中收集數(shù)據(jù)；問卷調(diào)查允許回答者匿名填寫，大多數(shù)用戶可能會(huì)提供真實(shí)信息；問卷調(diào)查的結(jié)果比較好整理和統(tǒng)計(jì)。但是問卷調(diào)查最大的不足就是缺乏靈活性，其他缺點(diǎn)還有：
  ① 雙方未見面，系統(tǒng)分析師無法從用戶的表情等其他動(dòng)作來獲取一些更隱性的信息，用戶也沒有機(jī)會(huì)立即澄清對(duì)問題有含糊或錯(cuò)誤的回答。
  ② 用戶有可能在心理上會(huì)不重視一張小小的表格，不認(rèn)真對(duì)待，從而使得反饋的信息不全面。
  ③ 調(diào)查表不利于對(duì)問題進(jìn)行展開的回答，無法了解一些細(xì)節(jié)問題。
  ④ 回答者的數(shù)量往往比預(yù)期的要少，無法保證用戶會(huì)回答問題或進(jìn)一步說明所有問題。

• 抽樣調(diào)查/采樣
  抽樣調(diào)查/采樣是指從種群中系統(tǒng)地選出有代表性的樣本集的過程，通過認(rèn)真研究所選出的樣本集，可以從整體上揭示種群的有用信息。對(duì)于信息系統(tǒng)的開發(fā)而言，現(xiàn)有系統(tǒng)的文檔（文件）就是采樣種群。當(dāng)開始對(duì)一個(gè)系統(tǒng)做需求分析時(shí)，查看現(xiàn)有系統(tǒng)的文檔是對(duì)系統(tǒng)有初步了解的最好方法。但是，系統(tǒng)分析師應(yīng)該查看哪些類型的文檔，當(dāng)文檔的數(shù)據(jù)龐大，無法一一研究時(shí)，就需要使用采樣技術(shù)選出有代表性的數(shù)據(jù)。采樣技術(shù)不僅可以用于收集數(shù)據(jù)，還可以用于采集訪談?dòng)脩艋蛘呤遣杉^察用戶。在對(duì)人員進(jìn)行采樣時(shí)，上面介紹的采樣技術(shù)同樣適用。通過采樣技術(shù)，選擇部分而不是選擇種群的全部，不僅加快了數(shù)據(jù)收集的過程，而且提高了效率，從而降低了開發(fā)成本。另外，采樣技術(shù)使用了數(shù)理統(tǒng)計(jì)原理，能減少數(shù)據(jù)收集的偏差。
  但是，由于采樣技術(shù)基于統(tǒng)計(jì)學(xué)原理，樣本規(guī)模的確定依賴于期望的可信度和已有的先驗(yàn)知識(shí)，很大程度上取決于系統(tǒng)分析師的主觀因素，對(duì)系統(tǒng)分析師個(gè)人的經(jīng)驗(yàn)和能力依賴性很強(qiáng)，要求系統(tǒng)分析師具有較高的水平和豐富的經(jīng)驗(yàn)。

• 聯(lián)合需求計(jì)劃（JRP）
  JRP是一種相對(duì)來說成本較高的需求獲取方法，但也是十分有效的一種。它通過聯(lián)合各個(gè)關(guān)鍵用戶代表、系統(tǒng)分析師、開發(fā)團(tuán)隊(duì)代表一起，通過有組織的會(huì)議來討論需求。通常該會(huì)議的參與人數(shù)為6～18人，召開時(shí)間為1～5小時(shí)。
  JRP的主要意圖是收集需求，而不是對(duì)需求進(jìn)行分析和驗(yàn)證。實(shí)施JRP時(shí)應(yīng)把握以下主要原則：
  ① 在JRP實(shí)施之前，應(yīng)制訂詳細(xì)的議程，并嚴(yán)格遵照議程進(jìn)行。
  ②按照既定的時(shí)間安排進(jìn)行。
  ③盡量完整地記錄會(huì)議期間的內(nèi)容。
  ④在討論期間盡量避免使用專業(yè)術(shù)語。
  ⑤充分運(yùn)用解決沖突的技能。
  ⑥會(huì)議期間應(yīng)設(shè)置充分的間歇時(shí)間。
  ⑦鼓勵(lì)團(tuán)隊(duì)取得一致意見。
  ⑧保證參加JRP的所有人員能夠遵守事先約定的規(guī)則。

2.5.2 需求分析

需求分析：一個(gè)好的需求應(yīng)該具有無二義性、完整性、一致性、可測(cè)試性、確定性、可跟蹤性、正確性、必要性等特性，因此，需要分析人員把雜亂無章的用戶要求和期望轉(zhuǎn)化為用戶需求，這就是需求分析的工作。

需求分析的任務(wù)：
（1）繪制系統(tǒng)上下文范圍關(guān)系圖
（2）創(chuàng)建用戶界面原型
（3）分析需求的可行性
（4）確定需求的優(yōu)先級(jí)
（5）為需求建立模型
（6）創(chuàng)建數(shù)據(jù)字典
（7）使用QFD（質(zhì)量功能部署)

2.5.2.1 結(jié)構(gòu)化分析方法 - SA

結(jié)構(gòu)化分析方法SA的核心是數(shù)據(jù)字典。圍繞這個(gè)核心有三個(gè)層次的模型，分別是數(shù)據(jù)模型，功能模型，行為模型（狀態(tài)模型）。

結(jié)構(gòu)化分析的步驟，如下：
（1）分析業(yè)務(wù)情況，做出反映當(dāng)前物理模型的數(shù)據(jù)流圖（Data Flow DiagramDFD）。
（2）推導(dǎo)出等價(jià)的邏輯模型的DFD。
（3）設(shè)計(jì)新的邏輯系統(tǒng)，生成數(shù)據(jù)字典和基元描述。
（3）建立人機(jī)接口，提出可供選擇的目標(biāo)系統(tǒng)物理模型的DFD。
（5）確定各種方案的成本和風(fēng)險(xiǎn)等級(jí)，據(jù)此對(duì)各種方案進(jìn)行分析。
（6）選擇一種方案。
（7）建立完整的需求規(guī)約。

結(jié)構(gòu)化分析方法SA是數(shù)據(jù)流和控制流，常用手段是數(shù)據(jù)流圖（DFD）和數(shù)據(jù)字典。

2.5.2.1.1 SA - 數(shù)據(jù)字典DD

數(shù)據(jù)字典是需求分析建立模型的核心。是為數(shù)據(jù)流圖中的每個(gè)數(shù)據(jù)流、文件、加工，以及組成數(shù)據(jù)流或文件的數(shù)據(jù)項(xiàng)做出說明。

數(shù)據(jù)字典有4類條目：數(shù)據(jù)流、數(shù)據(jù)項(xiàng)、數(shù)據(jù)存儲(chǔ)和基本加工。包括了數(shù)據(jù)元素，數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)流，加工邏輯和外部實(shí)體。如下圖：

2.5.2.1.2 SA - 數(shù)據(jù)流圖DFD

數(shù)據(jù)流圖DFD是用數(shù)據(jù)流圖表示功能模型，DFD說明系統(tǒng)所完成功能，從數(shù)據(jù)傳遞和加工的角度，利用圖形符號(hào)通過逐層細(xì)分描述系統(tǒng)的各個(gè)部件的功能和數(shù)據(jù)在他們之間傳遞的情況，來說明系統(tǒng)所完成的功能。如下圖：

其中，DFD還會(huì)有“頂層DFD圖”和“0層DFD圖”。

如上圖，有如下幾種“圖元”描述：

另附一個(gè)錯(cuò)誤的DFD圖，如下：

如上圖錯(cuò)誤：

加工3.1.2有輸入但是沒有輸出，稱之為“黑洞”。
加工3.1.3有輸出但沒有輸入。稱之為“奇跡”。
加工3.1.1中輸入不足以產(chǎn)生輸出，我們稱之為“灰洞”。

2.5.2.1.3 SA - 狀態(tài)轉(zhuǎn)換圖STD

用狀態(tài)轉(zhuǎn)換圖表示行為模型，STD通過描述系統(tǒng)的狀態(tài)和引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為，指出做為特定事件的結(jié)果將執(zhí)行哪些動(dòng)作。如下圖：

2.5.2.1.4 SA - E-R圖/實(shí)體聯(lián)系圖

ER圖主要描述實(shí)體屬性，以及實(shí)體之間的關(guān)系。另外，ER模型是結(jié)構(gòu)化時(shí)代的模型與產(chǎn)物，在面向?qū)ο蠛蚒ML中是沒有的。如下圖：

什么是弱實(shí)體？
舉例說明：在人事管理系統(tǒng)中，職工子女的信息就是以職工的存在為前提的，子女實(shí)體是弱實(shí)體，子女與職工的聯(lián)系是一種依賴聯(lián)系。所以，職工是實(shí)體，也可以成為強(qiáng)實(shí)體。
強(qiáng)實(shí)體與弱實(shí)體的聯(lián)系只能是1：1或1：N。

2.5.2.2 面向?qū)ο蟮姆治龇椒?- OOA

相關(guān)的幾個(gè)概念

OOA大致上遵循如下5個(gè)基本步驟：

（1）確定對(duì)象和類：這里所說的對(duì)象是對(duì)數(shù)據(jù)及其處理方式的抽象，它反映了系統(tǒng)保存和處理現(xiàn)實(shí)世界中某些事物的信息的能力。類是多個(gè)對(duì)象的共同屬性和方法集合的描述，它包括如何在一個(gè)類中建立一個(gè)新對(duì)象的描述。
（2）確定結(jié)構(gòu)：結(jié)構(gòu)是指問題域的復(fù)雜性和連接關(guān)系。類成員結(jié)構(gòu)反映了泛化-特化關(guān)系，整體-部分結(jié)構(gòu)反映整體和局部之間的關(guān)系。
（3）確定主題：主題是指事物的總體概貌和總體分析模型。
（4）確定屬性：屬性就是數(shù)據(jù)元素，可用來描述對(duì)象或分類結(jié)構(gòu)的實(shí)例，可在圖中給出，并在對(duì)象的存儲(chǔ)中指定。
（5）確定方法：方法是在收到消息后必須進(jìn)行的一些處理方法:方法要在圖中定義，并在對(duì)象的存儲(chǔ)中指定。對(duì)于每個(gè)對(duì)象和結(jié)構(gòu)來說，那些用來增加、修改、刪除和選擇的方法本身都是隱含的（雖然它們是要在對(duì)象的存儲(chǔ)中定義的，但并不在圖上給出），而有些則是顯示的。

2.5.2.2.1 OOA - UML

OOA需求分析的UML（統(tǒng)一建模語言，與平臺(tái)和語言無關(guān)）由基本構(gòu)造塊，規(guī)則和公共機(jī)制構(gòu)成。

UML基本構(gòu)造塊之事物【重要組成部分】

UML基本構(gòu)造塊之關(guān)系【把事物緊密聯(lián)系在一起】

UML基本構(gòu)造塊之圖【多個(gè)相互關(guān)聯(lián)的事物的集合】

UML規(guī)則

是構(gòu)造塊如何放在一起的規(guī)定，包括為構(gòu)造塊命名；給一個(gè)名字以特定含義的語境，即范圍；怎樣使用或看見名字，即可見性；事物如何正確、一致地相互聯(lián)系，即完整性；運(yùn)行或模擬動(dòng)態(tài)模型的含義是什么，即執(zhí)行。

UML公共機(jī)制

是指達(dá)到特定H標(biāo)的公共UML方法，主要包括規(guī)格說明（詳細(xì)說明）、修飾、公共分類（通用劃分）和擴(kuò)展機(jī)制4種。規(guī)格說明是事物語義的細(xì)節(jié)描述，它是模型真正的核心：UML為每個(gè)事物設(shè)置了一個(gè)簡(jiǎn)單的記號(hào)，還可以通過修飾來表達(dá)更多的信息；UML包括兩組公共分類：類與對(duì)象（類表示概念，而對(duì)象表示具體的實(shí)體)、接門與實(shí)現(xiàn)（接口用來定義契約，而實(shí)現(xiàn)就是具體的內(nèi)容)；擴(kuò)展機(jī)制包括約束（擴(kuò)展了UML構(gòu)造塊的語義，允許增加新的規(guī)則或修改現(xiàn)有的規(guī)則）、構(gòu)造型（擴(kuò)展UML的詞匯，用于定義新的構(gòu)造塊）和標(biāo)記值（擴(kuò)展了UML構(gòu)造塊的特性，允許創(chuàng)建新的特殊信息來擴(kuò)展事物的規(guī)格說明）。

UML中的概念

• 類：是描述具有相同屬性、方法、關(guān)系和語義的對(duì)象的集合，一個(gè)類實(shí)現(xiàn)一個(gè)或多個(gè)接口。
• 接口：是指類或構(gòu)件提供特定服務(wù)的一組操作的集合，接口描述了類或構(gòu)件的對(duì)外的可見的動(dòng)作。
• 構(gòu)件：是物理上或可替換的系統(tǒng)部分，它實(shí)現(xiàn)了一個(gè)接口集合。提供一組接口的實(shí)現(xiàn)，是組成事物的元素。
• 包：是用于把元素組織成組的通用機(jī)制，它一個(gè)構(gòu)件的抽象化的概念，是把類元按照一定的規(guī)則分成組（或稱為模塊）。
• 用例：是描述一系列的動(dòng)作，產(chǎn)生有價(jià)值的結(jié)果。
• 協(xié)作：定義了交互的操作，是一些角色和其它事物一起工作，提供一些合作的動(dòng)作，這些動(dòng)作比事物的總和要大。
• 節(jié)點(diǎn)：是一個(gè)物理元素，它在運(yùn)行時(shí)存在，代表一個(gè)可計(jì)算的資源，通常占用一些內(nèi)存和具有處理能力。

2.5.2.2.2 OOA - UML 4+1視圖

現(xiàn)有的UML，再有的UML視圖

UML采用4+1視圖來描述軟件和軟件的開發(fā)過程，其中進(jìn)程視圖繪制了所設(shè)計(jì)的并發(fā)與同步結(jié)構(gòu)；部署視圖表示軟件到硬件的映射和分布結(jié)構(gòu)；UML中的類圖可以用來表示4+1視圖中邏輯視圖；最終形成用例視圖，用來得到需求分析模型。

“4+1”視圖模型是從不同的視角、使用多個(gè)并發(fā)的視圖來組織軟件架構(gòu)的描述。

“4+1”視圖模型具有普遍適用性，實(shí)踐證明能在許多大型項(xiàng)目中成功運(yùn)用。

2.5.2.2.3 OOA - 用例模型與分析模型

在OOA的需求分析中，圖的應(yīng)用是經(jīng)常被用到的。大部分的以用例模型和分析模型的建立為主線，其中用例模型采用用例圖來構(gòu)建，分析模型用類型表示。其它細(xì)節(jié)情況，也可以建立其它交互圖。

2.5.2.2.4 需求分析工具

2.5.2.2.4.1 使用用例建模系統(tǒng)需求

用例建模來源于面向?qū)ο蠼＜夹g(shù)，但該技術(shù)也在非對(duì)象開發(fā)環(huán)境中比較流行，用例建模技術(shù)對(duì)傳統(tǒng)的系統(tǒng)分析和設(shè)計(jì)工具進(jìn)行了補(bǔ)充，例如數(shù)據(jù)建模和過程建模， 也提供了架構(gòu)決策和用戶界面設(shè)計(jì)決策的基礎(chǔ)。

用例建模促進(jìn)并鼓勵(lì)了用戶參與，具有如下優(yōu)點(diǎn)：

• 提供了捕捉功能需求的工具。
• 有助于將系統(tǒng)分解為更易于管理的小塊。
• 提供了與用戶以及其他關(guān)心系統(tǒng)的關(guān)聯(lián)人員進(jìn)行交流的工具。
• 輔助估計(jì)項(xiàng)目范圍、投入和進(jìn)度。
• 提供了需求跟蹤的工具。
• 提供了確定數(shù)據(jù)對(duì)象或?qū)嶓w的起點(diǎn)。
• 提供了設(shè)計(jì)用戶和系統(tǒng)接口的功能規(guī)格說明。

為了決定用例的重要性，項(xiàng)目經(jīng)理或者系統(tǒng)分析員將填寫用例分級(jí)和評(píng)估矩陣，并使用來自關(guān)聯(lián)人員和開發(fā)團(tuán)隊(duì)的輸入構(gòu)造用例依賴關(guān)系圖。

1、項(xiàng)目經(jīng)理使用稱為用例分級(jí)和評(píng)估矩陣，決定用例的優(yōu)先級(jí)。該矩陣使用6個(gè)標(biāo)準(zhǔn)按1 ~ 5級(jí)評(píng)估用例。6個(gè)標(biāo)準(zhǔn)是：

• 對(duì)架構(gòu)設(shè)計(jì)的重要影響。
• 容易實(shí)現(xiàn)但包含重要功能。
• 包含有風(fēng)險(xiǎn)、時(shí)間緊迫或復(fù)雜的功能。
• 需要大量的研究或者新的、有風(fēng)險(xiǎn)的技術(shù)。
• 包含主要的業(yè)務(wù)功能。
• 將增加或者減少費(fèi)用。

2、有些用例依賴于其他用例，其中一個(gè)用例使系統(tǒng)處于一種狀態(tài)，該狀態(tài)是另一個(gè)用例的前置條件。我們使用用例依賴關(guān)系圖建模這種依賴關(guān)系。用例依賴關(guān)系圖具有以下優(yōu)點(diǎn)：

• 系統(tǒng)事件及其狀態(tài)的圖形化表述有利于對(duì)系統(tǒng)功能的理解。
• 有助于確定遺漏的用例。
• 通過描述哪個(gè)用例更關(guān)鍵并需要最高優(yōu)先權(quán)，有助于推動(dòng)項(xiàng)目管理。

2.5.2.2.4.1 數(shù)據(jù)建模與分析

數(shù)據(jù)建模是一種為數(shù)據(jù)庫(kù)定義業(yè)務(wù)需要的技術(shù)，因?yàn)閿?shù)據(jù)模型最終要實(shí)現(xiàn)成數(shù)據(jù)庫(kù)，所以數(shù)據(jù)建模有時(shí)稱為數(shù)據(jù)庫(kù)建模。下圖是一個(gè)簡(jiǎn)單的數(shù)據(jù)模型，稱為實(shí)體關(guān)系圖。

數(shù)據(jù)建模的系統(tǒng)概念：

• 實(shí)體
• 屬性（數(shù)據(jù)類型、域、默認(rèn)值）（鍵）
• 關(guān)系

如何構(gòu)造數(shù)據(jù)模型？

• 獲取實(shí)體。
• 構(gòu)造上下文數(shù)據(jù)模型：包含基本業(yè)務(wù)實(shí)體及它們之間的自然關(guān)系。
• 基于鍵的數(shù)據(jù)模型：確定每個(gè)實(shí)體的鍵。
• 泛化層次體系：父實(shí)體、子實(shí)體。
• 具有完整屬性的數(shù)據(jù)模型。
• 分析數(shù)據(jù)模型：規(guī)范化（第一范式、第二范式、第三范式）。
• 將數(shù)據(jù)需求映射到地點(diǎn)：數(shù)據(jù)–地點(diǎn)–CRUD矩陣。

2.5.2.2.4.1 過程建模

過程建模源自傳統(tǒng)的軟件工程方法，可能的過程模型包括程序結(jié)構(gòu)圖、邏輯流程圖或決策表。本節(jié)重點(diǎn)介紹系統(tǒng)分析的過程模型，即數(shù)據(jù)流圖。 數(shù)據(jù)流圖是一種描述通過系統(tǒng)的數(shù)據(jù)流以及系統(tǒng)實(shí)施的工作或處理過程的工具。同義詞包括泡式圖、轉(zhuǎn)換圖和過程模型。

過程建模的系統(tǒng)概念：

• 外部代理：常見的同義詞包括外部實(shí)體。
• 數(shù)據(jù)存儲(chǔ)：是一個(gè)數(shù)據(jù)的“倉(cāng)庫(kù)”，同義詞包括文件和數(shù)據(jù)庫(kù)。
• 過程：即處理，是在輸入數(shù)據(jù)流或條件上執(zhí)行，或者對(duì)輸入數(shù)據(jù)流或條件做出響應(yīng)的工作，同義詞是轉(zhuǎn)換。分解圖、層次圖。注意避免過程中三種常見的錯(cuò)誤：1）有輸入沒有輸出，黑洞；2)有輸出但沒有輸入，奇跡；3)輸入不足以產(chǎn)生輸出，灰洞（如輸入一個(gè)雇員地址，輸出一張財(cái)務(wù)報(bào)表）。
• 數(shù)據(jù)流：所有的過程至少都有一個(gè)輸入流和一個(gè)輸出流。數(shù)據(jù)流是過程與系統(tǒng)環(huán)境之間的通信。在數(shù)據(jù)流圖中，有時(shí)需要描述分支的數(shù)據(jù)流或合并的數(shù)據(jù)流。分支的數(shù)據(jù)流是一個(gè)分成多個(gè)數(shù)據(jù)流的數(shù)據(jù)流，表示一個(gè)數(shù)據(jù)流的所有或者部分路由到不同目的地。合并的數(shù)據(jù)流是多個(gè)數(shù)據(jù)流合并成一個(gè)數(shù)據(jù)流后的數(shù)據(jù)流。合并的數(shù)據(jù)流指示了不同來源的數(shù)據(jù)流可以合并成一個(gè)報(bào)文供后續(xù)處理。

如何構(gòu)造過程模型：

• 構(gòu)造上下文數(shù)據(jù)流圖：0號(hào)數(shù)據(jù)流圖。
• 構(gòu)造系統(tǒng)功能分解圖。
• 事件響應(yīng)或用例清單：構(gòu)建分解圖后，下一步是確定系統(tǒng)必須響應(yīng)什么業(yè)務(wù)事件，（外部事件、時(shí)序事件、狀態(tài)事件）。發(fā)現(xiàn)并確定事件和響應(yīng)的更成功的方法之一是用例的技術(shù)。用例分析是確定并建模業(yè)務(wù)事件、誰觸發(fā)事件以及系統(tǒng)如何響應(yīng)事件的過程。
• 事件分解圖：把事件處理過程增加到分解圖中。
• 事件圖：以分解圖為提綱，可以為每個(gè)事件過程繪制一個(gè)事件圖。
• 構(gòu)造系統(tǒng)圖：從原始的上下文圖中的單個(gè)過程“爆炸”出來，在單張圖中顯示了系統(tǒng)的所有事件，顯示了子系統(tǒng)的所有事件。 構(gòu)造基本圖：具有較復(fù)雜的事件圖的事件過程應(yīng)該擴(kuò)展成一個(gè)更詳細(xì)的基本數(shù)據(jù)流圖，每個(gè)基本過程都是內(nèi)聚的，也就是說僅完成一件事。
• 完成規(guī)格說明：對(duì)以上完成的數(shù)據(jù)流圖中的每個(gè)數(shù)據(jù)流、數(shù)據(jù)存儲(chǔ)和基本過程進(jìn)行描述，并寫進(jìn)資料庫(kù)中。對(duì)于過程內(nèi)部的邏輯描述，我們可以使用結(jié)構(gòu)化英語（自然英語+編程邏輯），用于說明過程模型中的基本過程的內(nèi)部邏輯。但許多過程是由復(fù)雜的條件組合的（即業(yè)務(wù)策略），使用結(jié)構(gòu)化英語不容易表達(dá)，此時(shí)可以使用決策表。

2.5.2.2.4.1 面向?qū)ο蠓治雠c建模

面向?qū)ο蠓治錾婕暗蕉x信息系統(tǒng)的靜態(tài)和動(dòng)態(tài)行為模型，而非定義數(shù)據(jù)和過程模型（這是傳統(tǒng)開發(fā)方法的特點(diǎn)）。對(duì)象的標(biāo)識(shí)，對(duì)象的數(shù)據(jù)部分（屬性），對(duì)象的行為。

2.5.3 需求定義（形成需求規(guī)格）

需求定義的過程也就是形成需求規(guī)格說明書SRS的過程，通常有兩種需求定義的方法，分別是嚴(yán)格定義方法和原型方法。

嚴(yán)格定義法的特點(diǎn)：所有需求都能夠被嚴(yán)格定義；開發(fā)人員和用戶之間能夠準(zhǔn)確而清晰的交流；采用圖形文字能夠充分體現(xiàn)最終系統(tǒng)。

原型法：并非所有的需求都能在開發(fā)前被準(zhǔn)確的說明；項(xiàng)目參加者之間通常存在交流上的困難；需要實(shí)際的可供用戶參與的系統(tǒng)模型；有合適的系統(tǒng)開發(fā)環(huán)境；反復(fù)是完全需要和值得提倡的，需求一旦確定就應(yīng)該遵從嚴(yán)格的方法。

2.5.4 需求確認(rèn)與驗(yàn)證

需求規(guī)格說明書SRS的需求驗(yàn)證也稱為需求確認(rèn)，其活動(dòng)是為了確定以下幾個(gè)方面的內(nèi)容：

（1）SRS正確地描述了預(yù)期的、滿足項(xiàng)目干系人需求的系統(tǒng)行為和特征。
（2）SRS中的軟件需求是從系統(tǒng)需求、業(yè)務(wù)規(guī)格和其他來源中正確推導(dǎo)而來的。
（3）需求是完整的和高質(zhì)量的。
（4）需求的表示在所有地方都是一致的。
（5）需求為繼續(xù)進(jìn)行系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試提供了足夠的基礎(chǔ)。

需求驗(yàn)證包括了需求評(píng)審和需求測(cè)試。

需求評(píng)審包括了：正式評(píng)審和非正式評(píng)審。需求驗(yàn)證是需要做用戶簽字確認(rèn)，但往往實(shí)施起來比較困難，因?yàn)樾枨篁?yàn)證時(shí)簽字就要負(fù)責(zé)任，它是驗(yàn)收的標(biāo)準(zhǔn)之一（此時(shí)的規(guī)格說明書SRS就是需求基線）。需求的評(píng)審需要用戶的參與。

需求測(cè)試，不是運(yùn)行類的測(cè)試而是設(shè)計(jì)測(cè)試用例進(jìn)行測(cè)試，比如告訴你輸入是什么輸出是什么，所以更加接近于想像性測(cè)試，它是驗(yàn)證方向?qū)Σ粚?duì)該不該做的過程。需求測(cè)試僅僅是基于文本需求進(jìn)行“概念”上的測(cè)試。然而，以功能需求為基礎(chǔ)（SA方法）或者從用例派生出來（OO方法）的測(cè)試用例，可以使項(xiàng)目干系人更清楚地了解系統(tǒng)的行為。雖然沒有在系統(tǒng)上執(zhí)行測(cè)試用例，但是涉及測(cè)試用例的簡(jiǎn)單動(dòng)作可以解釋需求的許多問題。這種測(cè)試用例通常稱為概念測(cè)試用例，即不是真正執(zhí)行的測(cè)試用例，它們可以發(fā)現(xiàn)SRS中的錯(cuò)誤、二義性和遺漏，還可以進(jìn)行模型分析，以及作為用戶驗(yàn)收測(cè)試的基礎(chǔ)。在正式的系統(tǒng)測(cè)試中，還可以將它們細(xì)化成測(cè)試用例。

2.6 需求管理（支持，保障）

在軟件需求工程中，需求管理貫穿于整個(gè)過程中，它的最基本的任務(wù)就是明確需求，并使項(xiàng)目團(tuán)隊(duì)和用戶達(dá)成共識(shí)，即建立需求基線。另外，還要建立需求跟蹤能力聯(lián)系鏈，確保所有用戶需求都被正確地應(yīng)用，并且在需求發(fā)生變更時(shí)，能夠完全地控制其影響范圍，始終保持產(chǎn)品與需求的一致性。

需求管理是可重復(fù)級(jí)的一個(gè)關(guān)鍵過程域，其目標(biāo)是為軟件需求建立一個(gè)基線，供軟件開發(fā)及其管理使用，使軟件計(jì)劃、產(chǎn)品和活動(dòng)與軟件需求保持一致。從軟件需求工程的角度來看，需求管理包括在軟件開發(fā)過程中維持需求一致性和精確性的所有活動(dòng)，包括控制需求基線，保持項(xiàng)目計(jì)劃與需求一致，控制單個(gè)需求和需求文檔的版本情況，管理需求和聯(lián)系鏈之間的聯(lián)系，或管理單個(gè)需求和項(xiàng)目其他可交付物之間的依賴關(guān)系，跟蹤基線中需求的狀態(tài)。

2.6.1 定義需求基線

需求開發(fā)的結(jié)果應(yīng)該有項(xiàng)目視圖和范圍文檔、用例文檔和SRS，以及相關(guān)的分析模型。經(jīng)評(píng)審批準(zhǔn)，這些文檔就定義了開發(fā)工作的需求基線。這個(gè)基線在用戶和開發(fā)人員之間就構(gòu)成了軟件需求的一個(gè)約定，它是需求開發(fā)和需求管理之間的橋梁。

基線是一個(gè)軟件配置管理的概念，它幫助開發(fā)人員在不嚴(yán)重阻礙合理變化的情況下來控制變化。根據(jù)IEEE的定義，基線是指已經(jīng)通過正式評(píng)審和批準(zhǔn)的規(guī)約或產(chǎn)品，它可以作為進(jìn)一步開發(fā)的基礎(chǔ)，并且只能通過正式的變更控制系統(tǒng)進(jìn)行變化。在軟件工程范圍內(nèi)，基線是軟件開發(fā)中的里程碑，其標(biāo)志是有一個(gè)或多個(gè)軟件配置項(xiàng)的交付，且已經(jīng)經(jīng)過正式技術(shù)評(píng)審而獲得認(rèn)可。例如，SRS文檔通過評(píng)審，其中的錯(cuò)誤已經(jīng)被發(fā)現(xiàn)并糾正，則就變成了一個(gè)基線。根據(jù)國(guó)家標(biāo)準(zhǔn)《計(jì)算機(jī)軟件配置管理計(jì)劃規(guī)范》（GB/T 12505-1990）的規(guī)定，基線可以分為功能基線、指派基線和產(chǎn)品基線三種，通過評(píng)審后的SRS（軟件需求規(guī)格說明書）屬于指派基線。

2.6.2 需求的狀態(tài)

在需求狀態(tài)的變化中，項(xiàng)目管理人員首先需要關(guān)注的是那些被拒絕和被丟棄的需求。因?yàn)檫@些需求有可能是應(yīng)該被接受和并被實(shí)現(xiàn)的需求，如果不是通過有管理的處理過程，就有可能因?yàn)槭韬龆贿z漏。同時(shí)，也應(yīng)關(guān)注被交付的需求，因?yàn)榭山桓段锸琼?xiàng)目的成果體現(xiàn)，而可交付物的主要內(nèi)容就是對(duì)需求的實(shí)現(xiàn)。

2.6.3 需求變更管理

CCB，變更控制委員會(huì)，也成配置控制委員會(huì)。
要讓變更有序進(jìn)行，首先需要有一個(gè)統(tǒng)一的單位來負(fù)責(zé)，這個(gè)單位一般叫變更控制委員會(huì)（Change
Control Board），也叫配置控制委員會(huì)（Configuration Control
Board）。CCB由項(xiàng)目干系人中有代表性的人員組成，人數(shù)沒有限制，一個(gè)人也可以。CCB有能力在管理上做出承諾，對(duì)建議的配置項(xiàng)變更做出評(píng)價(jià)、審批及監(jiān)督已批準(zhǔn)變更的實(shí)施。CCB是決策機(jī)構(gòu)，一般不參與具體的變更執(zhí)行工作。

2.6.4 需求變更管理過程

（1）問題分析和變更描述。當(dāng)提出一份變更提議后，需要對(duì)該提議做進(jìn)一步的問題分析，檢查它的有效性，從而產(chǎn)生一個(gè)更明確的需求變更提議。
（2）變更分析和成本計(jì)算。當(dāng)接受該變更提議后，需要對(duì)需求變更提議進(jìn)行影響分析和評(píng)估。變更成本計(jì)算應(yīng)該包括對(duì)該變更所引起的所有改動(dòng)的成本，例如修改需求文檔、相應(yīng)的設(shè)計(jì)、實(shí)現(xiàn)等工作成本。一旦分析完成并且被確認(rèn)，應(yīng)該進(jìn)行是否執(zhí)行這一變更的決策。
（3）變更實(shí)現(xiàn)。當(dāng)確定執(zhí)行該變更后，需要根據(jù)該變更的影響范圍，按照開發(fā)的過程模型執(zhí)行相應(yīng)的變更。在計(jì)劃驅(qū)動(dòng)過程模型中，往往需要回溯到需求分析階段開始，重新作對(duì)應(yīng)的需求分析、設(shè)計(jì)和實(shí)現(xiàn)等步驟;在敏捷開發(fā)模型中，往往會(huì)將需求變更納入到下一次迭代的執(zhí)行過程中。

常見的需求變更策略：

（1）所有需求變更必須遵循變更控制過程。
（2）對(duì)于未獲得批準(zhǔn)的變更，不應(yīng)該做設(shè)計(jì)和實(shí)現(xiàn)工作。
（3）變更應(yīng)該由項(xiàng)目變更控制委員會(huì)決定實(shí)現(xiàn)哪些變更。
（4）項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者應(yīng)該能夠了解變更的內(nèi)容。
（5）絕不能從項(xiàng)目配置庫(kù)中刪除或者修改變更請(qǐng)求的原始文檔。
（6）每一個(gè)集成的需求變更必須能跟蹤到一個(gè)經(jīng)核準(zhǔn)的變更請(qǐng)求，以保持水平可追蹤性。

2.6.5 需求風(fēng)險(xiǎn)

帶有風(fēng)險(xiǎn)的做法有：①無足夠用戶參與。②忽略了用戶分類。③用戶需求的不斷增加。④模凌兩可的需求。⑤不必要的特征。⑥過于精簡(jiǎn)的SRS。⑦不準(zhǔn)確的估算。

變更產(chǎn)生的原因：①外部環(huán)境的變化。②需求和設(shè)計(jì)做的不夠完整。③新技術(shù)的出現(xiàn)。④公司機(jī)構(gòu)重組造成業(yè)務(wù)流程的變化。

2.6.6 需求跟蹤

SRS中的每個(gè)軟件配置項(xiàng)的需求到其涉及的系統(tǒng)（或子系統(tǒng)）需求都要具有雙向可追蹤性。所謂雙向跟蹤，包括正向跟蹤和反向跟蹤，正向跟蹤是指檢查SRS中的每個(gè)需求是否都能在后繼工作成果中找到對(duì)應(yīng)點(diǎn)；反向跟蹤也稱為逆向跟蹤，是指檢查設(shè)計(jì)文檔、代碼、測(cè)試用例等工作成果是否都能在SRS中找到出處。文章來源地址http://www.zghlxwxcb.cn/news/detail-642209.html

到了這里，關(guān)于系統(tǒng)架構(gòu)設(shè)計(jì)專業(yè)技能 · 軟件工程（一）【系統(tǒng)架構(gòu)設(shè)計(jì)師】的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！