標籤: 暫無標籤

需求管理(Requirement management)是完整管理模式中的一環,同其他特性諸如完整性、一致性等不可分割,彼此相關而成一體。一套需求管理應當是已知系統需求的完整體現,每部分解決方案都是對總體需求一定比例的滿足(甚至是充分滿足),僅僅解決部分需求是沒有意義的。對關鍵需求的疏忽很可能是災難性的,試想一架飛機的安全設計不過關將會帶來什麼樣的後果。不同的需求組合起來,構成了一套完整的需求模型。用戶需求決定了系統設計所要解決的問題,所要帶來的結果。可以說,需求管理指明了系統開發所要做和必須做的每一件事,指明了所有設計應該提供的功能和必然受到的制約。

1 需求管理 -需求管理的過程

 從需求獲取開始貫於整個項目生命周期,力圖實現最終產品同需求的最佳結合。通過對需求管理在項目進程中實施的不同任務進行分析,我們可以看出需求理所起的作用。 需求管理本就是一個動態的過程,離開了能動的、變化的系統進程而空談需求管理,無異於紙上談兵。需求管理恰如裁縫的量體裁衣,它直接關係到最終產品的成型。僅從字面出發,如果一個產品滿足了客戶需求,那它無疑就是成功的。需求管理的過程,從需求分析開始貫穿整個項目始終,力圖最終產品同需求性的最佳結合(參見Figure 1)。通過對需求管理在項目進程中實施的不同任務進行分析,我們可以看出需求管理所起的作用。 需求管理能夠確證:

     ●我們確知客戶的需求是什麼(質量);
      ●滿足客戶需求的最佳解決辦法(統一性);

需求管理

      著名學者Crosby對於質量的定義是"同需求保持統一"。從這個意義上說,需求管理正是從質量出發以確定需求。每個人都應當始終明白他們所做的具體任務其意義何在。然而,在一個產品的生命周期里,其需求性是能動的,是處於變化之中的。

      對於系統工程沒有嚴格統一的定義,因此很難找到足夠的數據以說明系統工程所起的作用。有些致力於研究需求分析的組織認為,一項開發計劃應當至少將8-15%的資源投入到系統工程方面。如果低於這一標準,將很可能導致無法對客戶群做出準確把握。如果該項開發計劃含有許多創新或實驗的成分,那麼這一百分比還應當適度提高。

 定義需求(Define Requirement)

      在項目進展過程中,如何區分用戶需求與需求分析中需求定義呢?

      當完成用戶需求調查后,首先對《用戶需求說明書》進行細化,對比較複雜的用戶需求進行建模分析,以幫助軟體開發人員更好地理解需。例如採用Rational 的Rose工具進行需求的建模分析。如果使用工具進行建模分析,對需求分析人員的要求比較高。

      當完成需求的定義及分析后,需要將此過程書面化,要遵循既定的規範將需求形成書面的文檔,我們通常稱之為《需求分析說明書》。

      邀請同行專家和用戶(包括客戶和最終用戶)一起評審《需求規格說明書》,盡最大努力使《需求規格說明書》能夠正確無誤地反映用戶的真實意願。需求評審之後,開發方和客戶方的責任人對《需求規格說明書》作書面承諾。具體的同行評審詳見需求評審章節。

需求確認(Requirement Validate)

      需求確認是需求管理過程中的一種常用手段,也是需求控制的五一節之一;確認有兩個層面的意思,第一是進行系統需求調查與分析的人員與客戶間的一種溝通,通過溝通從而對需求不一致的進行剔除;另外一個層面的意思是指,對於雙方達成共同理解或獲得用戶認可的部分,雙方需要進行承諾。

建立需求狀態

      何謂需求狀態;顧名思義,狀態也就是一種事物或實體在某一個時刻或點所處的情況,此處要講的需求狀態是指用戶需求的一種狀態變換過程。

      為什麼要建立需求狀態?在整個生命周期中,存在著有幾種不同的情況,在需求調查人員或系統分析人員進行需求調查時,客戶存在的需求可能有多種,一類是客戶可以明確且清楚的提出的需求;一類是客戶知道需要做些什麼,但又不能確定的需求;另一類是客戶本身可以得出這類需求,但需求的業務不明確,還需要等待外部信息。還有是客戶本身也說不清楚的。

      對於這些需求,在開發進展的過程中,存在著以下幾種情況:
      有可能要取消的
      有的因為不明確而可以後延的,同時可能轉化為被取消的需求
      與客戶經過溝通或確認的,此處有兩種情況,一類是確認雙方達成共識,另一種情況是還需要再進一步溝通的。

      下面是一個簡單的狀態例子:
      CLOSED:經過確認,雙方認可並達成共識;
      OPEN:雙方確認,但沒有達成共識的需求;
      待定:客戶提出需求,但雙方沒有經過溝通或確認;

需求評審(Requirement Review)

      對工作產品的評審有兩類方式,一類是正式技術評審,也稱同行評審,另一類是非正式技術評審。對於任何重要的工作產品,都應該至少執行一次正式技術評審。在進行正式評審前,需要有人員對其要進行評審的工作產品進行把關,確認其是否具備進入評審的初步條件。

      需求評審的規程與其它重要工作產品(如系統設計文檔、源代碼)的評審規程非常相似,主要區別在於評審人員的組成不同。前者由開發方和客戶方的代表共同組成,而後者通常來源於開發方內部。

      有人問:需求評審究竟評審什麼?要細到什麼程度?怎麼樣進行?

      嚴格地講,應當檢查需求文檔中的每一個需求,每一行文字,每一張圖表。評判需求優劣的主要指標有:正確性、清晰性、無二義性、一致性、必要性、完整性、可實現性、可驗證性、可測性。如果有可能,最好可以制定評審的檢查表。

      需求評審面臨的困難及對策如下:

      需求評審的一個通病是「虎頭蛇尾」。需求評審的確乏味,也比較費腦子。剛開始評審時,大家都比較認真,越到後頭越馬虎。當需求文檔很長時,幾乎沒人能夠堅持到最後。會議主持人事先要強調需求評審的重要性:認真評審一小時可能會避免將來數十天的「返工」,讓大家足夠重視。評審組長還要設法避免大家在昏昏沉沉中評審。如果評審時間比較長,建議每隔兩小時休息一次。另外,如果系統比較大,也可以細分成不同的部分分別進行,嚴格控制每一次評審的文檔規模及持續時間。

      需求評審涉及的人員可能比較多,有些時候讓這麼多人聚在一起花費比較長的時間開會並不容易(例如有些人可能出差在外,有些人可能事務纏身)。沒有必要把所有事情擠在一塊做,需求開發是循序漸進的過程,需求評審也可以分段進行。這樣每次評審的時間比較短,參加評審的人員也少一些,組織會議就比較容易。對於需求的工作產品《需求規格說明書》,我們可以標明幾種文檔狀態,如草稿狀態。評審狀態,初始狀態等。只有進入評審狀態時,我們可以用不同的方式來對文檔進行評審。但當其評審狀態轉化為初始狀態時,需要進行嚴格的正式的同行評審。

      開評審會議時經常會「跑題」,導致評審效率很低。有時話匣子一打開后關不上,大家越扯越遠,結果評審會議變成了聊天會議。主持人應當控制話題,避免大家討論與主題無關的東西。對於自主研發的產品,由於需求評審人員大部分是開發人員,大家會不知不覺地談論軟體「如何做」。由於需求是否「可實現、可驗證、可測試」本來就屬於需求評審的範疇,所以強制大家「只談做什麼,不談怎麼做」幾乎是不可能的。那麼,在需求的評審會上,需要允許開發人員談如何做,但不需太細,適而可止。同時,評審會必須明確一位評審組長,對時間與問題進行控制。

      開評審會議時經常會發生爭議。適當的爭議有利於澄清問題,比什麼東西都一致贊成要好。然而當爭議變為爭吵時就壞事了。爭吵不僅對評審工作沒有好處,而且會無意中傷害同事們的感情。同時也解決不了問題。所以,在評審會的過程中,我們要儘可能的是在闡述事實與證據,而並不是從你心底要如何地說服別人。

      人們在很多時候分不清楚自己究竟是「堅持真理」還是「固執己見」。毫不妥協或者輕易妥協都不是好辦法。我們應當養成良好的習慣:不要一棍子打死異己的觀點,嘗試著讓自己站在他人的立場思考問題,這樣你會找到比較滿意的答案。試著從不同的角度去看同樣的問題。


{項目名稱}評審報告_需求
基本信息
工作產品.版本號
名稱,標識符,版本,作者,時間

工作產品標識號

 
評審方式

第幾次評審

 
工作產品存放路徑

 
評審地點

評審時間

 
參與人員

 
評審人員名字
工作單位或部門
職務職稱
簽字

 
 
 
 
 
 
問題記錄及處理意見
問題編號
位置
問題描述
問題類型
嚴重程度

Problem A

 
 
 
 
Problem B

 
 
 
 
評審結論

評審結論
【 】 工作產品合格,「無需修改」或者「需要輕微修改但不必再審核」。
【√】 工作產品基本合格,需要作少量的修改,之後通評審組長檢查即可。
【 】 工作產品不合格,需要作比較大的修改,之後必須重新對其評審。

簽字

 

 
 

需求承諾(Requirement Consent)

      什麼是需求承諾,是指開發方和客戶方的責任人對通過了同行評審的需求階段的工作產品,作出承諾,同時該承諾具有商業合同的同等效果。 需求承諾如下:

需求承諾
XXX項目需求文檔_《XXX需求說明書》,版本號:X.X.X,是建立在XXX與XXX雙方共同對需求理解的基礎之上,同意後續的開發工作根據該工作產品開展。如果需求發生變化,雙方將共同遵循項目定義的「變更控制規程」執行。需求的變更將導致雙方重新協商成本、資源和進度等。
甲方簽字
乙方簽字

      不少人會草率地??面簽字嗎,反正已經評審過了,我就簽吧。但他將來變更需求時可能會表示不瞞:「不錯,我是簽字了,但是我並沒有閱讀文檔。是你們要我在文檔上簽字的,我是相信你們才這麼做的。」為了避免發生此類糾紛,人們在作出承諾之前務必要認真閱讀文檔,一定要明白簽字意味著什麼。

需求跟蹤(Requirement Track)

      為什麼要進行需求跟蹤?在整個開發過程中,進行需求跟蹤的目的是為了建立和維護從用戶需求開始到測試之間的一致性與完整性。確保所有的實現是以用戶需求為基礎。對於需求實現是否全部的覆蓋。同時確保所有的輸出與用戶需求的符合性。

      需求跟蹤有兩種方式,正向跟蹤與逆向跟蹤:

      正向跟蹤:以用戶需求為切入點,檢查《用戶需求說明書》或《需求規格說明書》中的每個需求是否都能在後繼工作產品中找到對應點。
      逆向跟蹤:檢查設計文檔、代碼、測試用例等工作產品是否都能在《需求規格說明書》中找到出處。
正向跟蹤和逆向跟蹤合稱為「雙向跟蹤」。不論採用何種跟蹤方式,都要建立與維護《需求跟蹤矩陣》。需求跟蹤矩陣保存了需求與後續開發過程輸出的對應關係。矩陣單元之間可能存在「一對一」、「一對多」或「多對多」的關係。見下表:簡單的需求跟蹤矩陣示例。

需求代號需求規格說明書V1.0設計文檔V1.2代碼1.0測試用例測試記錄
R001標題或標識符標題或標識符代碼文件名稱 測試用例標識或名稱
R002 
 

2 需求管理 -簡單的需求跟蹤矩陣示例1

      使用需求跟蹤矩陣的優點是很容易發現需求與後續工作產品之間的不一致,有助於開發人員及時糾正偏差,避免干冤枉活。

      很多人有這樣的誤解:如果依照「需求開發-系統設計-編碼-測試」這樣的順序開發產品,由於每一步的輸出就是下一步的輸入,所以不必擔心設計、編程、測試會與需求不一致,因此可以省略需求跟蹤。那麼,需要指正的是,按照軟體生命周期嚴格線性順序的開發模型並不能保證各個開發階段的工作產品與需求保持一致。因為開發者是人而不是機器。而且,大多數開發人員也都深有體會。

      生活中「以訛傳訛」的例子,想必大家都很熟悉。學生甲在精工實習時被機器弄破了手指,於是到醫院包紮。同學乙路過醫院時看到甲的手血跡斑斑,以為甲的手指被機器割斷,於是將這個壞消息告訴同學丙。丙急忙轉告同學丁,說甲的手被機器割斷,正躺在醫院裡。丁十萬火急地告訴全班同學,大家陷入悲痛之中,都以為「甲的胳膊被機器割斷了,正躺在醫院裡,人快不行了。」

      由於人們的表達能力、理解能力不可能完全相同,人與人之間的協作很難達到天衣無縫的境界。而使用需求追溯的本身也是一種傳遞的過程。

      需求追溯本身並不是一件複雜的事,而是我們的本身一種理念在支配著我們。也許就有人認為這本身就是在浪費時間,主要麻煩是,當需求或工作產品發生變更時,開發人員要及時更新需求跟蹤矩陣。然而沒想到的事,如果後來再花時間來做同樣的事的時候,將會付出更多。也時也就丟去了本身做這件事的意義。

3 需求管理 -需求變更控制(Requirement Change Control)

      需求變更通常會對項目的進度、人力資源產生很大的影響,這是開發商非常畏懼的問題。也是必須面臨與需要處理的問題。作為軟體項目,特別在外地實施的工程軟體項目而言,需求發生若干次變更似乎是不可避免的。需求發生變更的起因主要有:

      隨著項目生命周期的不斷往前推進,人們(包括開發方和客戶方)對需求的了解越來越深入。原先的提出的需求可能存在著一定的缺陷,因此要變更需求。
      市場業務需求發生了變化,原先的需求可能跟不上當前的市場業務發展,因此要變更需求。由於市場變化而導致需求發生變更,開發商大可不必為此煩惱,應當高興才對。倘若市場靜如死水,那麼開發商吃了「上一頓」就沒有「下一頓」。正因為市場在變化,才會產生更多商機,聰明的開發商才會有活干,有錢賺。
      如果在項目開發的初始階段,開發人員和用戶沒有搞清楚需求或者搞錯了需求,到了項目開發後期才將需求糾正過來,導致產品的部分內容需要重新開發。毫無疑問,這種需求??方工作失誤造成的,雙方應當好好反省,認真學習需求開發和管理的方法,避免再犯相似的錯誤。

      總的而言,人們提出需求變更,本就是出於能夠是產品更加符合市場或客戶需求,出發點本身是好的。但對於開發小組而言,需求的變更則意味著要需要重新進行估計,調整資源、重新分配任務、修改前期工作產品等,而作為開發商,需要增預算與投資,開發組要為此付出較重的代價。假定每次需求變更請求都被接受的話,那麼這個項目將會成為一個連環式的工程。

4 需求管理 -需求變更控制的動機是:

      如果需求變更帶來的好處大於坏處,那麼允許變更,但必須按照已定義的變更規程執行,以免變更失去控制。
      如果需求變更帶來的壞處大於好處,那麼拒絕變更。
      當然,好處與壞處並不是主觀的,而是通過客觀的分析與評價而得出的。
      對於需求的變更,在某一個程度上來說,也就是項目的範圍進行了變化。而需求同時又是項目進行的基礎。是非常得要的基石。通常對於需求的變更需要客戶與開發方共同參與,包括負責人及市場人員。當然,我們需要根據變更的內容來靈活運用。
      需求變更控制過程中最難辦的事情是莫過於「拒絕客戶提出的需求變更請求」。客戶會想當然地以為變更需求是他的權利,因為他付錢給開發方。通常情況下開發方是不敢得罪客戶的,但是無原則地退讓將使開發小組陷入困境。怎麼解決這個問題呢,通常情況下,每一類「遊戲」都有一定的遊戲規則,那麼我們事先也需要建立「遊戲規則」。
      如果事先沒有「遊戲規則」的話,開發方的負責人需要一些社交技巧來減緩矛盾。例如首先承認客戶提出的需求變更請求是合理的,再闡述己方的難處,最後建議在開發該產品新版本時修改需求。這種方式比直接拒絕有效得多,既不得罪客戶,又為自己爭取了餘地。
      另外還有一種方法,可以將變更需求先進行記錄,並通知給客戶,當其需求變化在開發組不能接受的範圍時,可以通過市場進行相關的協調。
      需求變更本是正常的,並不可怕,可怕的是需求的變更得不到控制。

 

       從上述的分析可以看出,需求的捕獲是需求管理的基礎和前提.在這裡,將介紹一種為業界所廣泛採用並經驗證的需%E4%BE%8B%E6%A8%A1%E5%9E%8B  求的一個類.通過確定需求類型,團隊可以把大量需求組織成意義明確且更容易管理的組.在一個項目中建立不同類型的需求有助於團隊成員對變更請求進行分類,並使相互之間的溝通更為清楚明確.從上述的分析中我們可以看到,通常,一類需求可以細分即分解成其他類型的需求.這裡,我們就把需求分解為幾種類型,並在他們之間建立相應的關聯.業務規則和前景聲明包括高層次的需求,團隊可以從中導出用戶需要,特性和產品需求類型.用例和其他建模形式驅動設計需求,該需求可分解為軟體需求,並可以用分析設計模型來說明.測試需求源於軟體需求,它被分解為具體的測試過程.如果既定項目中有成百上千個,甚至上萬個需求實例時,對需求進行分類可以使項目更容易管理.上述的這些需求類型同時保存在對應的RUP文檔和資料庫中.

5 需求管理 -應用需求類型

      通過定義需求類型,以及他們之間的關係,我們就建立了一個需求管理模型的框架.當然,我們建立這樣的一個模型,是為了方便我們使用需求,為了達到這一目的,我們還需要在此基礎上添加相應的內容. 需要對各種需求類型添加它們的屬性,以便於對需求進行查詢等管理手段.比如,可以針對用戶需要,確定該需要的必要性,優先順序,確定性等屬性.在實際的項目中,就可以確定這些屬性的值,而後根據這些實際屬性值來安排項目的進度表等.或是在項目進度緊急時,確定哪些需求是可以延期完成,而哪些是必須完成的,等等.

      需求的追蹤性 其次,可以根據不同需求的導出情況,在不同的需求之間建立追蹤關係.譬如,用戶需要決定了要構建產品的特性,產品的特性又決定了產品的軟體需求,等.在這些不同類型的需求之間建立關聯,一旦其中的某些需求發生變化,就可以確定它可能帶來的影響,從而制定相應的策略.

 

上一篇[竭斯底里症]    下一篇 [風險管理]

相關評論

同義詞:暫無同義詞