需求管理:經濟學術語-中文百科頻道

概述

定義

需求（DefineRequirement）在項目進展過程中，如何區分用戶需求與需求分析中需求定義呢？

凱恩斯認為，在市場發揮作用的前提下，不能實現供求總量平衡，而存在着有效需求不足。

當完成用戶需求調查後，首先對《用戶需求說明書》進行細化，對比較複雜的用戶需求進行建模分析，以幫助軟件開發人員更好地理解需求。例如采用Rational的Rose工具進行需求的建模分析。如果使用工具進行建模分析，對需求分析人員的要求比較高。需求定義過程中通常會出現的問題有内容失實、遺漏、含糊不清和前後描述不一緻。

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

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

确認

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

建立狀态

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

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

對于這些需求，在開發進展的過程中，存在着以下幾種情況:

有可能要取消的，有的因為不明确而可以後延的，同時可能轉化為被取消的需求。與客戶經過溝通或确認的，此處有兩種情況，一類是确認雙方達成共識，另一種情況是還需要再進一步溝通的。

下面是一個簡單的狀态例子：

CLOSED：經過确認，雙方認可并達成共識；

OPEN:雙方确認，但沒有達成共識的需求；

待定：客戶提出需求，但雙方沒有經過溝通或确認；

評審

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

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

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

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

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

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

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

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

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

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

{項目名稱}評審報告_需求

基本信息

工作産品。版本号

名稱，标識符，版本，作者，時間

工作産品标識号

評審方式

第幾次評審

工作産品存放路徑

評審地點

評審時間

參與人員

評審人員名字

工作單位或部門

職務職稱

簽字

問題記錄及處理意見

問題編号

位置

問題描述

問題類型

嚴重程度

ProblemA

ProblemB

評審結論

【】工作産品合格，“無需修改”或者“需要輕微修改但不必再審核”。

【√】工作産品基本合格，需要作少量的修改，之後通評審組長檢查即可。

【】工作産品不合格，需要作比較大的修改，之後必須重新對其評審。

簽字

承諾

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

需求承諾

XXX項目需求文檔_《XXX需求說明書》，版本号：X。X。X，是建立在XXX與XXX雙方共同對需求理解的基礎之上，同意後續的開發工作根據該工作産品開展。如果需求發生變化，雙方将共同遵循項目定義的“變更控制規程”執行。需求的變更将導緻雙方重新協商成本、資源和進度等。

甲方簽字

乙方簽字

跟蹤

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

需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤：

正向跟蹤：以用戶需求為切入點，檢查《用戶需求說明書》或《需求規格說明書》中的每個需求是否都能在後繼工作産品中找到對應點。

逆向跟蹤：檢查設計文檔、代碼、測試用例等工作産品是否都能在《需求規格說明書》中找到出處。

正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護《需求跟蹤矩陣》。需求跟蹤矩陣保存了需求與後續開發過程輸出的對應關系。矩陣單元之間可能存在“一對一”、“一對多”或“多對多”的關系。

矩陣示例

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

很多人有這樣的誤解：如果依照“需求開發－系統設計－編碼－測試”這樣的順序開發産品，由于每一步的輸出就是下一步的輸入，所以不必擔心設計、編程、測試會與需求不一緻，因此可以省略需求跟蹤。那麼，需要指正的是，按照軟件生命周期嚴格線性順序的開發模型并不能保證各個開發階段的工作産品與需求保持一緻。需求開發包括獲取分析需求，需求定義，從所有方面核查和驗證需求。因為開發者是人而不是機器。而且，大多數開發人員也都深有體會。

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

了。”

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

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

變更控制

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

随着項目生命周期的不斷往前推進，人們（包括開發方和客戶方）對需求的了解越來越深入。原先的提出的需求可能存在着一定的缺陷，因此要變更需求。

市場業務需求發生了變化，原先的需求可能跟不上當前的市場業務發展，因此要變更需求。由于市場變化而導緻需求發生變更，開發商大可不必為此煩惱，應當高興才對。倘若市場靜如死水，那麼開發商吃了“上一頓”就沒有“下一頓”。正因為市場在變化，才會産生更多商機，聰明的開發商才會有活幹，有錢賺。

如果在項目開發的初始階段，開發人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發後期才将需求糾正過來，導緻産品的部分内容需要重新開發。毫無疑問，這種需求?方工作失誤造成的，雙方應當好好反省，認真學習需求開發和管理的方法，避免再犯相似的錯誤。

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

需求變更控制的動機是：

如果需求變更帶來的好處大于壞處，那麼允許變更，但必須按照已定義的變更規程執行，以免變更失去控制。

如果需求變更帶來的壞處大于好處，那麼拒絕變更。

當然，好處與壞處并不是主觀的，而是通過客觀的分析與評價而得出的。

對于需求的變更，在某一個程度上來說，也就是項目的範圍進行了變化。而需求同時又是項目進行的基礎。是非常得要的基石。通常對于需求的變更需要客戶與開發方共同參與，包括負責人及市場人員。當然，需要根據變更的内容來靈活運用。

需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。客戶會想當然地以為變更需求是他的權利，因為他付錢給開發方。通常情況下開發方是不敢得罪客戶的，但是無原則地退讓将使開發小組陷入困境。怎麼解決這個問題呢，通常情況下，每一類“遊戲”都有一定的遊戲規則，那麼事先也需要建立“遊戲規則”。

如果事先沒有“遊戲規則”的話，開發方的負責人需要一些社交技巧來減緩矛盾。例如首先承認客戶提出的需求變更請求是合理的，再闡述己方的難處，最後建議在開發該産品新版本時修改需求。這種方式比直接拒絕有效得多，既不得罪客戶，又為自己争取了餘地。

另外還有一種方法，可以将變更需求先進行記錄，并通知給客戶，當其需求變化在開發組不能接受的範圍時，可以通過市場進行相關的協調。

需求變更本是正常的，并不可怕，可怕的是需求的變更得不到控制。

需要原因

簡單地說，系統開發團隊之所以管理需求，是因為他們想讓項目獲得成功。滿足項目需求即為成功打下了基礎。若無法管理需求，達到目标的幾率就會降低。以下最近收集的證據很有說服力:StandishGroup從1994年到2001年的CHAOSReports證實，導緻項目失敗的最重要的原因與需求有關。2001年，StandishGroup的CHAOSReports報導了該公司的一項研究，該公司對多個項目作調查後發現，百分之七十四的項目是失敗的，既這些項目不能按時按預算完成。其中提到最多的導緻項目失敗的原因就是"變更用戶需求"。

管理模型

在需求管理的流程中，需求的捕獲手段固然重要，但在需求的捕獲和需求最終成型的過程中，會面臨各種和需求相關的信息和資料(也可以把這些信息籠統地稱做"需求")，如何發現這些信息之間的關系并有效組織，更為關鍵。需求類型在RUP中，采用一種金字塔方式的管理辦法，來組織和管理獲取的信息乃至最終的需求。

為了建立一個真正滿足客戶需求的系統，項目團隊首先必須确定系統要解決的問題。然後，團隊必須确定涉衆，從中獲得業務和用戶需要，對其進行描述，并區分它們的優先級。從這一組高層期望或需求出發，對産品或系統特性集達成一緻意見。而後，由産品特性來抽取軟件需求，在的模型中，軟件需求是以用例模型的方式來描述。從測試的角度來看，測試項一定來自于軟件需求，即軟件需求中确定了哪些需求項，測試就要根據這些需求項來制定和實現。

系統越大越複雜，出現的需求類型就越多。一個需求類型不過是指需求的一個類。通過确定需求類型，團隊可以把大量需求組織成意義明确且更容易管理的組。在一個項目中建立不同類型的需求有助于團隊成員對變更請求進行分類，并使相互之間的溝通更為清楚明确。從上述的分析中可以看到，通常，一類需求可以細分即分解成其他類型的需求。這裡，就把需求分解為幾種類型，并在他們

之間建立相應的關聯。業務規則和前景聲明包括高層次的需求，團隊可以從中導出用戶需要，特性和産品需求類型。用例和其他建模形式驅動設計需求，該需求可分解為軟件需求，并可以用分析設計模型來說明。測試需求源于軟件需求，它被分解為具體的測試過程。如果既定項目中有成百上千個，甚至上萬個需求實例時，對需求進行分類可以使項目更容易管理。上述的這些需求類型同時保存在對應的RUP文檔和數據庫中

需求預測模型

1、主觀判斷預測。主觀判斷預測涉及利用主觀判斷和直覺，适用于數據有限或無曆史數據的情況，例如引入新産品。主觀判讀預測技術包括調研和類比技術等。

2、時間序列預測。其基本假設是未來需求僅由過去需求決定。時間序列預測技術包括但不限于簡單移動平均。

和加權移動平均。

3、因果預測。因果預測假設一個或多個因素與需求相關，而因果關系可用來估計未來的需求。

工作流程

工作流明細簡介

問題分析

問題分析可以通過了解問題及涉衆的最初需要，并提出高層解決方案來實現。它是為找出"隐藏在問題之後的問題"而進行的推理和分析。問題分析期間，将對"什麼是面臨實際問題"和"誰是涉衆"等問題達成一緻。而且，您還要從業務角度界定解決方案，以及制約該解決方案的因素。您應該已經對項目進行過商業理由分析，這将便于您更好地預計能從構建中的項目中得到多少投資回報。

理解涉衆

需求來自各個方面，比如來自客戶，合作夥伴，最終用戶或是某領域的專家。您需要掌握如何準确判斷需求應來源于哪方面，如何接近這些來源并從中獲取信息。提供這些信息主要出處的個人在本項目中稱為涉衆。如果您正在開發一個在您公司内部使用的信息系統，那麼在開發團隊中應包括具有最終用戶經驗和業務領域專業知識的人員。通常讨論将在業務模型這一級上展開，而不是在系統這一級上展開。

如果正在開發一個要在市場上出售的産品，那麼您可以充分調動營銷人員，以便更好地了解該市場中用戶的需要。獲取需要的活動可使用這樣一些技巧:訪談，集體讨論，概念原型設計，問卷調查和競争性分析等。獲取結果可能是一份圖文并茂的請求或需要列表，并按相互之間的優先級列出。

定義系統

定義系統指的是解釋涉衆需求，并整理為對要構建系統的意義明确的說明。在系統定義的初期要确定以下内容:需求構成，文檔格式，語言形式，需求的具體程度(需求量及詳細程度)，需求的優先級和預計工作量(不同人在不同的實踐中通常對這兩項内容的看法大不相同)，技術和管理風險以及最初規模。系統定義活動還可包括與最關鍵的涉衆請求直接聯系的初期原型和設計模型。

項目規模

為使項目高效運作，應仔細根據所有涉衆的需求确定優先級，并對項目規模進行管理。有的開發人員僅僅重視所謂的"複活節彩蛋"(即開發人員感興趣或覺得有挑戰性的特性)，而不是及早将精力投入降低項目風險或提高應用程序構架穩定性方面，這已使太多的項目蒙受損失。為确保盡早解決或降低項目中的風險，應以遞增的方式開發系統。要慎重選擇需求，以确保每次增加都能緩解項目中的已知風險。要達到目的，您需要和項目的涉衆協商每次叠代的範圍。通常，這要求具備管理項目各個階段的期望結果的良好技能。

除了控制開發過程本身，您還需控制需求的來源，并控制項目可交付工件的外觀。改進系統定義系統的詳細定義應能讓涉衆理解，同意并認可。它不僅需要具備所有功能，而且應符合法律或法規上的要求，符合可用性，可靠性，性能，可支持性和可維護性。感覺構建過程複雜的系統就應該有複雜的定義，這是一種常見的錯誤看法。這會給解釋項目和系統的目的造成困難。人們可能印象深刻，但他們會因不甚理解而無法給出建議。應該緻力了解您制作的系統說明文檔的讀者。您可能常會發現需要為不同的讀者準備不同的說明文檔。

認為用例方法是傳達系統目的和定義系統細節的一種行之有效的方法，它常與簡單的可視化原型結合使用。用例有助于為需求提供一個環境，利用它可生動地說明系統使用的方式。

系統詳細定義的另一個構件是說明系統采用的測試方式。測試計劃及要執行測試的定義将會說明要核實哪些系統功能。

變更

定義需求時無論怎樣謹慎小心，也總會有可變因素。變更的需求之所以變得難以管理，不僅是因為一個變更了的需求意味着要花費或多或少的時間來實現某一個新特性，而且也因為對某個需求的變更很可能影響到其他需求。應确保賦予需求一個有彈性的結構，使它能适應變更，并且确保使用可追蹤性鍊接可以表達需求與開發生命周期的其他工件之間的依賴關系。管理變更包括建立基線，确定需要追蹤的重要依賴關系，建立相關項之間的可追蹤性，以及變更控制等活動。

任務

可以說需求是一種模型，是産品的早期雛形，通過進行需求分析，可以對最終産品做出優化。需要始終保持注意的是，需求性是始終處于變化之中的。需求管理需要完成的任務包括：

●明确需求并達成共識；

●建立關聯；

●根據不同需求設計相應解決辦法；

●進行系統優化；

●提出設計方案；

●監控和解決可能出現的問題以及需要做出的改變；

●控制不同開發任務的開展；

●對最終産品做出評測；

●監控可能出現的重複開發；

●提出項目實施時間表；

●确定最終用戶界面。

有時候所進行的需求分析隻停留于分析本身，而沒有進一步去思索為什麼要進行需求分析。需求性是項目開發的源頭，隻有進行認真的需求分析，才能做到對症下藥、量體裁衣，才能才設計開發中去僞存真，不斷改進。"需求之需求"正是強調了貫穿始終的需求分析的重要。離開了能動的、變化的系統進程而空談需求管理，無異于紙上談兵。需求管理所産生的效益或許并不明顯，或許要日後才能體現，但是無序的，沒有經過精心策劃的需求管理是不可能産生效益的。

以下篇幅分别介紹需求管理在系統工程中的不同應用。

共識

首先，用戶需求通過非術語的形式進行表述，這種表述應當使每一位開發者明确自己的職責所在，并且清楚知道不同開發工作之間的關聯。這裡的"用戶"泛指在實際應用環境中每一位可能使用最終産品的人。如果一個産品不能滿足客戶所需，那麼設計方案再出色也無濟于事，許多方案有很高的技術設計水準卻最終不能獲得成功，其原因正在于此。可以把産品功能說得天花亂墜，但卻無法改變用戶需求決定最終産品基本模式的事實。

需求管理的首要任務在于使開發人員和用戶雙方對于需求都有一個明确的認識。因此用來進行需求分析的語言組織應當使所有相關人員，包括用戶，都能夠理解，都能夠進而對整個項目有一個整體把握，并明确每一個人在項目中所起的作用。因而需求管理需要解決的第一位也是最基本的任務就是明确需求，并使所有相關人員達成共識。

根據需求設計解決辦法

在進行系統設計時，應當首先建立一個需求模型，但不能是為了建模而建模，需求模型實際是最終産品的抽象化表現。需求模型的建立使在明确需求的基礎上更進一步，使知道将要生産何種産品，該産品都具有那些功能。同時，創建需求模型的過程也使開發者明确自己的工作如何同整個項目有機地結合在一起。建立需求模型應當充分研究不同類型、不同架構建模方式的可行性，切忌主觀武斷。

系統優化

任何設計都應以考慮用戶需求為優先，用戶需求的滿足程度即成為衡量設計優劣的标準。在一個項目設計周期中，開發人員經常會面臨選擇，以提煉需求，決定開發的優先次序，并在不同的實施方案中作出選擇。這些選擇必須考慮到收益與付出地平衡比例，這種選擇的重要性尤其在建立需求模型的後期凸現出來。基本需求在這時都已明确，而實施方案還未敲定，為了使用戶的基本需求得到落實，一定程度的開銷用于搭建不同構架的需求模式是合理的。假使已經有了一套翔實的需求分析，甚至不必将每一套方案都付諸實行，就可以成功地對系統設計進行優化。

面對不同的可行性而需要作出選擇時，也必須參照收益與付出的比例關系。例如，在被要求提供計劃書時（RequestforProposal），應當盡量做到每一份計劃書的提供都物有所值。

方案設計

明确需求後，開發人員就可以進行方案設計。通過對用戶需求和設計方案之間所存在關聯性進行分析比較，就能夠對設計方案進行評估。

修改

方案的設計不可能是一成不變的，經常會有方案設計同需求相悖的情況。如果無法準确把握用戶需求同方案設計之間的關系，就無法在需要對方案進行必要修改時正确判斷。優秀的需求分析應當非常精确細緻地對用戶需求作出描述，同時也應該最大程度地給予方案設計者充分發揮的餘地。

任務劃分

一個大的開發項目可能涉及20-30組不同的開發隊伍，人員包括技術工程師、軟件工程師以及具體項目主管等等，而每一個模塊都有它自己的開發工具和開發語言。

主持一個大項目的開發并不是件容易的事，總體項目主管的首要任務是對開發項目進行任務劃分，将整體開發任務細化為多個子模塊，從而使這些子模塊能夠平行開發而無需太多的幹預。總體項目主管可以将細化的不同模塊的需求分析交給不同的開發隊伍，對于開發進程的監控隻需參照需求的解決情況，對于具體的開發細節則不必過問太多。

不同的開發隊伍會使用不同的開發語言和開發工具，會使用不同的符号和标記。相反，作為總體項目主管所使用的語言、符号和标記等則必須簡單易懂，以使所有的開發人員都等理解。換言之，總體項目主管應當使用自然語言，或隻涉及少量的，簡單的術語和專用詞彙。

産品測試

需求的滿足情況是決定最終産品成敗的判定基礎，對最終産品的測試評估必須以産品所試圖解決的需求為标準。下圖标示了不同的開發階段所對應的測試需求。

這裡有一個需求、産品和測試系統之間的關系問題，确定需要進行的測試屬于總體開發主管的工作範疇，雖然具體工作并非都要由開發主管來親自完成。

重複開發

對于總體開發主管而言，針對方案設計的修改是一項經常性的工作（因為修改而造成的影響則應當盡可能減小）。在進行項目開發時，随着開發進程的深入，各種修改的建議和問題的報告是屢見不鮮的，每解決一個問題，就是将産品同其需求性的結合又完善了一步。存在問題正是需求性尚未滿足的表現。

方案設計的完善和需求性的滿足是同步的，因此真正的用戶對于産品的評價和建議尤其具有重要意義。在那些一步到位的産品設計中，真正用戶無法左右開發進程；但在一個能夠進行重複設計、重複開發的産品生命期中，開發人員應當及時搜集用戶對于産品的反饋信息，并将這些信息結合到下一步的開發工作中去。如下圖所示，用戶反饋同産品開發是統一的。