軟件項目的需求開發(fā)與管理

1、軟件項目的需求開發(fā)與管理1什么是軟件需求和需求工程1.1 軟件需求的定義在IEEE軟件工程標(biāo)準(zhǔn)詞匯表(1997年)中定義軟件需求為：(1)用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。(2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具 有的條件或能力。(3) 一種反映上面(1)或(2)所描述的條件或權(quán)能的文檔說明。 實通俗的講, 需求”就是用戶的需要，它包括用戶要解決的問題、達(dá)到的目標(biāo)、以及實現(xiàn)這 些目標(biāo)所需要的條件，它是一個程序或系統(tǒng)開發(fā)工作的說明，表現(xiàn)形式一般為 文檔形式。1.2 需求工程的定義需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發(fā)和需求管 理兩個部分。需求開

2、發(fā)是指從情況收集、分析和評價到編寫文檔、評審等一系 列產(chǎn)生需求的活動，分為四個階段：情況獲取、分析、制訂規(guī)格說明和評審。 這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反復(fù)的。需求 管理是軟件項目開發(fā)過程中控制和維持需求約定的活動，它包括：變更控制、 版本控制、需求跟蹤、需求狀態(tài)跟蹤等工作。2需求分析的風(fēng)險由于需求分析的參與人員、業(yè)務(wù)模式、投資、時間等客觀因素的影響和需求 本身具有主觀性和可描述性差的特點，因此，需求分析工作往往面臨著一些潛 在的風(fēng)險。這些風(fēng)險主要表現(xiàn)在：(1)用戶不能正確表達(dá)自身的需求。在實際開發(fā)過程中，常常碰到用戶對 自己真正的需求并不是十分明確的情況，他們認(rèn)為計

3、算機是萬能的，只要簡單 的說說自己想干什么就是把需求說明白了，而對業(yè)務(wù)的規(guī)則、工作流程卻不愿 多談，也講不清楚。這種情況往往會增加需求分析工作難度，分析人員需要花 費更多的時間和精力與用戶交流，幫助他們梳理思路，搞清用戶的真實需求。(2)業(yè)務(wù)人員配合力度不夠。有的用戶日常工作繁忙，他們不愿意付出更 多的時間和精力向分析人員講解業(yè)務(wù)，這樣會加大分析人員的工作難度和工作 量，也可能導(dǎo)致因業(yè)務(wù)需求不足而使系統(tǒng)無法使用。(3)用戶需求的不斷變更。由于需求識別不全、業(yè)務(wù)發(fā)生變化、需求本身 錯誤、需求不清楚等原因，需求在項目的整個生命周期都可能發(fā)生變化，因 此，我們要認(rèn)識到，軟件開發(fā)的過程實際上是同變化做

4、斗爭的過程，需求變化 是每個開發(fā)人員、項目管理人員都會遇到的問題，也是最頭痛的問題，一旦發(fā) 生了需求變化，就不得不修改設(shè)計、重寫代碼、修改 測試用例、調(diào)整項目計劃 等等，需求的變化就像是萬惡之源，為項目的正常的進(jìn)展帶來不盡的麻煩。(4)需求的完整程度。需求如何做到?jīng)]有遺漏？這是一個大問題，大的系 統(tǒng)要想窮舉需求幾乎是不可能的，即使小的系統(tǒng)，新的需求也總會不時地冒出 來。一個系統(tǒng)很難確定明確的范圍并把所有需求一次性提出來，這會導(dǎo)致開發(fā) 人員在項目進(jìn)展中去不斷完善需求，先建立系統(tǒng)結(jié)構(gòu)再完成需求說明，造成返 工的可能性很大，會給開發(fā)人員帶來挫折感，降低他們完成項目的信心。(5)需求的細(xì)化程度。需求到

5、底描述到多細(xì)，才算可以結(jié)束了？雖然國家 標(biāo)準(zhǔn)有需求說明的編寫規(guī)范，但具體到某一個需求上，很難給出一個具體的指 標(biāo)，可謂仁者見仁，智者見智，并沒有定論。需求越細(xì)，周期越長，可能的變 化越多，對設(shè)計的限制越嚴(yán)格，對需求的共性提取要求也越高，相反，需求越 粗，開發(fā)人員在技術(shù)設(shè)計時不清楚的地方就越多，影響技術(shù)設(shè)計。(6)需求描述的多義性。需求描述的多義性一方面是指不同讀者對需求說 明產(chǎn)生了不同的理解；另一方面是指同一讀者能用不同的方式來解釋某個需求 說明。多義性會使用戶和開發(fā)人員等項目參與者產(chǎn)生不同的期望，也會使開 發(fā)、測試人員為不同的理解而浪費時間，帶來不可避免的后果便是返工重做。(7)忽略了用戶的

6、特點分析。分析人員往往容易忽略了系統(tǒng)用戶的特點， 系統(tǒng)是由不同的人使用其不同的特性，使用頻繁程度有所差異，使用者受教育 程度和經(jīng)驗水平不盡相同。如果忽略這些的話，將會導(dǎo)致有的用戶對產(chǎn)品感到 失望。(8)需求開發(fā)的時間保障。為了確保需求的正確性和完整性，項目負(fù)責(zé)人 往往堅持要在需求階段花費較多的時間，但用戶和開發(fā)部門的領(lǐng)導(dǎo)卻會因為項 目遲遲看不到實際成果而焦慮，他們往往會強迫項目盡快往前推進(jìn)，需求開發(fā) 人員也會被需求的復(fù)雜和善變折騰的筋疲力盡，他們也希望盡快結(jié)束需求階 段。3如何做好需求工作需求分析是軟件項目開發(fā)中最困難的一項工作，它不僅要求分析人員具有豐 富的需求分析經(jīng)驗和良好的專業(yè)素質(zhì)，還要

7、求分析人員具有良好的學(xué)習(xí)能力、 公關(guān)能力、語言能力和組織能力。在實際工作中分析人員要面對不同的單位、不同的部門、不同的人員、不同的文化、不同的關(guān)系、不同的管理水平等等不 同的情況，面對如此紛繁復(fù)雜的環(huán)境，如何做好需求分析工作？首先需要建立 一個有效的工作機制，只有建立了工作機制，才能保證需求工作按照既定方案 執(zhí)行，需求開發(fā)和管理的參與者才會在一種有序的狀態(tài)下工作。其次才是充分 運用工作機制和個人能力去獲取問題、分析問題、編寫需求文檔和進(jìn)行需求管 理。3.1 建立需求分析工作機制需考慮的幾個因素(1)抓住決策者最迫切和最關(guān)心的問題，引起重視。用戶方?jīng)Q策者對項目 的關(guān)心重視程度是項目能否順利開展的

8、關(guān)鍵，決策者的真實意圖也是用戶方的 最終需求，因此，在開發(fā)過程中要利用一切機會了解決策者關(guān)心的問題，同時 也要讓他們了解項目的情況。在諸如談判、專題匯報、協(xié)調(diào)會議、領(lǐng)導(dǎo)視察、 階段性成果演示等過程中用簡短明確的語言或文字抓住領(lǐng)導(dǎo)最關(guān)心的問題，引 導(dǎo)他們了解和重視項目的開發(fā)，當(dāng)決策者認(rèn)識到項目的重要性時，需求分析工 作在人力、物力、時間上就有了保障。(2)建立組織保障，明確的責(zé)任分工。項目開發(fā)一般都會成立相應(yīng)的項目 組或工程組，目前，常見的組織形式是：產(chǎn)品管理組、質(zhì)量與測試組、程序開 發(fā)組、用戶代表組和后勤保障組，各組的主要分工是：產(chǎn)品管理組負(fù)責(zé)確定和 設(shè)置項目目標(biāo)，根據(jù)需求的優(yōu)先級確定功能規(guī)范

9、，向相關(guān)人員通報項目進(jìn)展。 程序管理組負(fù)責(zé)系統(tǒng)分析，根據(jù)軟件開發(fā)標(biāo)準(zhǔn)協(xié)調(diào)日常開發(fā)工作確保及時交付 開發(fā)任務(wù)，控制項目進(jìn)度。程序開發(fā)組負(fù)責(zé)按照功能規(guī)范要求交付軟件系統(tǒng)。 質(zhì)量與測試組負(fù)責(zé)保證系統(tǒng)符合功能規(guī)范的要求，測試工作與開發(fā)工作是獨立 并行的。用戶代表組負(fù)責(zé)代表用戶方提出需求，負(fù)責(zé)軟件的用戶方測試。后勤 保障組負(fù)責(zé)確保項目順利進(jìn)行的后勤保障工作。(3)建立良好的溝通環(huán)境和氛圍。分析人員與用戶溝通的程度關(guān)系到需求 分析的質(zhì)量，因此建立一個良好的溝通氛圍、處理好分析人員與用戶之間的關(guān) 系顯得尤其重要，一般情況，用戶作為投資方會有一些心理優(yōu)勢，希望他們的 意見得到足夠的重視，分析人員應(yīng)該充分的認(rèn)識

10、到這一點，做好心理準(zhǔn)備，盡 量避免與他們發(fā)生爭執(zhí)，因為我們的目的是幫助用戶說出他們的最終需要。在 溝通時分析人員應(yīng)注意以下幾個方面：1)態(tài)度上要尊重對方，但不謙恭。謙 恭可能會讓用戶一時感到滿意，但對長期合作并沒有好處，尤其是在發(fā)生沖突 的時候，用戶會習(xí)慣性地感到自己的優(yōu)勢，而忽略分析人員地意見。2)分析人員要努力適應(yīng)不同用戶的語言表達(dá)方式。每個人都有自己的表達(dá)方式，所以 優(yōu)秀的分析人員應(yīng)該是一個優(yōu)秀的 傾聽者”，他們能很快的適應(yīng)用戶的語言風(fēng)格，理解他彳門的意思。3)善于表達(dá)自己，善于提問。分析人員在開口前應(yīng)該 先讓對方充分表達(dá)他的意思，在領(lǐng)會了后，自己再說，盡量不要搶話。4)工作外的交流有助

11、于增進(jìn)理解，加強溝通。(4)需求質(zhì)量控制要制度化需求的變化是軟件項目不可避免的事實，因此 需求質(zhì)量控制是一項艱苦的工作，要保證該項工作的順利實施，就必須有制度 保證，這個制度可以在項目質(zhì)量控制方案中制定，該方案主要是具體化、定量 化的描述用戶要求，形成全面、一致、規(guī)范的軟件需求分析規(guī)格說明書，明確 需求分析規(guī)格說明書的工作程序和要素，規(guī)范開發(fā)活動，為后續(xù)軟件設(shè)計、實 現(xiàn)、測試、評審及驗收提供依據(jù)。在方案中要明確項目組各部門關(guān)于需求質(zhì)量 控制的職責(zé)，制定需求分析的工作程序，包括編制需求分析工作計劃、編制需求分析說明書、需求分析規(guī)格說明書的評審和確認(rèn)、需求分析規(guī) 格說明書修改控制、確定需求質(zhì)量控制

12、的質(zhì)量記錄文檔規(guī)范等內(nèi)容。3.2 需求開發(fā)與管理的一些方法需求開發(fā)是一項復(fù)雜的工作，使用的方法也很多，不同的開發(fā)方式有不同的 方法，這里簡單介紹一些相關(guān)的方法：(1)繪制關(guān)聯(lián)圖：繪制系統(tǒng)關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界 限和接口的簡單模型。(2)可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行 性，提出需求實現(xiàn)相關(guān)風(fēng)險，包括與其它需求的沖突，對外界因素的依賴和技 術(shù)障礙。(3)需求優(yōu)先級：確定使用實例、產(chǎn)品特性或單項需求實現(xiàn)的優(yōu)先級別。 以優(yōu)先級為基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或哪類需求。(4)系統(tǒng)原型：當(dāng)用戶自身對有的需求不十分清楚時，我們可以建立一個 系統(tǒng)原型，用戶通過

13、評價原型更好地理解所要解決的問題。(5)圖形分析模型：繪制圖形分析模型是編制軟件需求規(guī)格說明重要手 段。它們能幫助分析人員理清數(shù)據(jù)、業(yè)務(wù)模式、工作流程以及他們之間的關(guān) 系，找出遺漏、冗余和不一致的需求。這樣的模型包括數(shù)據(jù)流圖、實體關(guān)系 圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。(6)數(shù)據(jù)字典：數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構(gòu)的定義，以確 保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù) 項，確?？蛻襞c開發(fā)小組是使用一致的定義和術(shù)語。(7)質(zhì)量功能調(diào)配：質(zhì)量功能調(diào)配是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、 屬性與對客戶的重要性聯(lián)系起來。該技術(shù)提供了一種分析方法以明確哪些是

14、客戶最為關(guān)注的特性。它將需求分為三類：期望需求、普通需求、興奮需求。需求管理的目的就是要控制和維持需求事先約定，保證項目開發(fā)過程的一致 性，使用戶得到他們最終想要得產(chǎn)品。需求管理的方法主要包括以下一些方 面：1）確定需求變更控制過程。制定一個選擇、分析和決策需求變更的過程， 所有的需求變更都需遵循此過程。2）進(jìn)行需求變更影響分析。評估每項需求變更，以確定它對項目計劃安排 和其它需求的影響，明確與變更相關(guān)的任務(wù)并評估完成這些任務(wù)需要的工作 量。通過這些分析將有助于需求變更控制部門做出更好的決策。3）建立需求基準(zhǔn)版本和需求控制版本文檔。確定需求基準(zhǔn)，這是項目各方 對需求達(dá)成一致認(rèn)識時刻的一個快照，

15、之后的需求變更遵循變更控制過程即 可。每個版本的需求規(guī)格說明都必須是獨立說明，以避免將底稿和基準(zhǔn)或新舊 版本相混淆。4）維護(hù)需求變更的歷史記錄。將需求變更情況寫成文檔，記錄變更日期、 原因、負(fù)責(zé)人、版本號等內(nèi)容，及時通知到項目開發(fā)所涉及的人員。為了盡量 減少困惑、沖突、誤傳，應(yīng)指定專人來負(fù)責(zé)更新需求。5）跟蹤每項需求的狀態(tài)。可以把每一項需求的狀態(tài)屬性（如已推薦的，已通過的，已實施的，或已驗證的）保存在 數(shù)據(jù)庫中、這樣可以在任何時候得到 每個狀態(tài)類的需求數(shù)量。6）衡量需求穩(wěn)定性。可以定期把需求數(shù)量和需求變更（添加、修改、刪 除）數(shù)量進(jìn)行比較。過多的需求變更”是一個報警信號”，意味著問題并未真正

16、弄清楚。4需求分析評價標(biāo)準(zhǔn)如何判斷需求規(guī)格說明的好壞，不同的軟件工程規(guī)范都有自己的一套標(biāo)準(zhǔn)， 這里向大家介紹一個比較常見的 NASA SEL推薦方法，它是由美國國家航空和 航天局軟件工程實驗室開發(fā)的五大常用國際軟件工程規(guī)范之一，它對軟件需求 過程的評價標(biāo)準(zhǔn)是：清晰、完整、一致、可測試。（1）清晰：目前大多數(shù)的需求分析采用的仍然是自然語言，自然語言對需 求分析最大的弊病就是它的二義性，所以開發(fā)人員需要對需求分析中采用的語 言做某些限制。例如盡量采用主語+動作的簡單表達(dá)方式。需求分析中的描述 一定要簡單，千萬不要采用疑問句、修飾這些復(fù)雜的表達(dá)方式。除了語言的二義性之外，注意不要使用行話，就是計算機術(shù)語。需求分析最重要的是和用 戶溝通，可是用戶多半不是計算機的專業(yè)人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難(2)完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返 工，在軟件開發(fā)過程中，最糟糕的事情莫過于在軟件開發(fā)接近完成時發(fā)現(xiàn)遺漏 了一項需求。但實際情況是，需求的遺漏是常發(fā)生的事情，這不僅僅是開發(fā)人 員的問題，更多發(fā)生在用戶那里。要做到需求的完整性是很艱難的一件事情， 它涉及到需求分析過程的各個方面，貫穿整個過程，從最初的需求計劃制定到 最后的需求評審。(3) 一致：一致性是指用戶需求必須和業(yè)務(wù)需求一致，功能需求必須和用 戶需求一致。